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EVALUATION 


Program  design  specifications  have  been  delivered  for  an  information 
structuring  method  that  will  be  applied  to  the  FTD  scientific  intelligence 
data  base.  It  Includes  specifications  for  an  entity  and  semantic  network 
structure,  as  well  as  directory  services  and  a peripheral  file  access 
system.  These  specifications  will  be  implemented  as  part  of  the  Scientific 
and  Technical  Intelligence  System  (STIS)  at  FTD.  This  effort  is  included 
as  part  of  TPO  Intelligence  Data  Handling. 

ROBERT  N.  RUBERTI 
Project  Engineer 
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SECTION  I.  INTRODUCTION 


OBJECTIVE 


Th«  objective  of  this  project  was  to  provide  technical  assistance 
to  the  developaent  team  of  the  Scientific  and  Technical  Intelligence  Systen 
(STIS)  (1]*  at  Air  Force  Foreign  Technology  Division  (FTD).  The  effort  was 
directed  at  the  design  and  docunentatlon  of  several  data  structures  and 
programed  capabilities  of  STIS.  These  Included  the  following: 


(a)  An  Indcxcd-Scquentlal  Access  Method  and  Directory 
for  encoding  and  decoding  STIS  user  and  system 
terms, 

(h)  the  data  structure  of  a generalized  STIS  node  which 
can  serve  for  the  elements  of  the  STIS  Concept  Net, 
including  entities,  seoantic  elements  (attributes 
and  values),  and  derivation  rules,  and 

(c)  a set  of  interpretations  of  the  node  structure  and 
the  definition  of  an  approach  which  can  be  used  by 
Che  analyst  in  representing  Intelligence  informa 
Cion  in  the  Concept  Net,  including  source  informa 
tion,  credibility,  everts,  states,  transitions, 
and  general  deductive  rules. 

^References  arc  listed  after  Che  main  body  of  this  report 
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BACKGROUND  OF  STIS 


STIS  is  being  developed  as  a tool  to  help  fulfill  the  Scien- 
tific and  Intelligence  analysis  mission  of  FTD.  It  serves  the  intelligence 
production  programs  in  application  areas  such  as  IPS  (Intelligence  Production 
System),  lEAS  (Integrated  Event  Analysis  System),  (Command,  Control,  and 
Communications),  and  EW  (Electronic  Warfare),  and  the  processing  of  metric 
sensor  data  performed  by  the  engineering  analyst  who  may  wish  to  operate  in 
an  interactive  mode  on-line  with  STIS  as  well  as  invoking  production  type 
programs. 

STIS  is  being  implemented  on  the  UNIVAC  1110  and  has  evolved 
from  a svstem  called  BIAS  which  was  orlainally  based  on  the  IBM  S/360  CIS. 

STIS  provides  an  advanced  capability  for  the  analysis  of  intelli- 
gence information.  It  is  based  on  a network  type  data  structure  which  per- 
mits relationships  among  entitles  and  new  attributes  to  be  freely  defined 
with  minimal  impact  on  previously  stored  data  and  programs.  Because  of 
this,  it  is  particularly  suited  for  capturing  fragmentary  information  which 
is  undergoing  collation  processing,  analysis,  evaluation,  and  synthesis 
into  finished  intelligence. 

In  another  research  effort,  called  the  BIAS  Augmentation  Study, 

AUERBACH  has  developed  the  design  of  advanced  relational  data  and  Inference 
providing  tools  for  use  in  an  operational  intelligence  environment.  The 
BIAS  Augmentation  Study  has  been  working  with  BIAS,  and  now  STIS,  as  a 
vehicle  with  which  to  develop  and  test  operations  on  relations,  inference, 
and  consistency  determining  functions.  The  ultimate  goal  is  to  incorporate 
thes  . advanced  capabilities  into  STIS  so  that  their  effectiveness  can  be 
accurately  evaluated,  and  these  new  tools  can  be  provided  to  the  STIS 
analyst. 


In  1973,  AUERBACH  Associates,  Inc.  developed  a design  for  an  in- 
ference capability  for  an  intelligence  system  such  as  STIS  [2] . The  design 
concept  of  this  capability,  called  ARIAS  (Augmented  Relational  Intelligence 
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Analysis  System),  embraced  both  inductive  and  deductive  Inferences  that  an 
analyst  may  desire  to  pursue  tn  testing  an  hypothesis  (or  answering  an  In- 


terrogation) concerning  the  current  state-of-af fairs  as  reflected  in  an 
Intelligence  data  base.  As  a result  of  a subsequent  project,  the  algorithms 
concerned  with  the  deductive  aspects  of  this  capability,  and  Its  interface 
with  STIS,  have  been  recently  detailed  (3). 


The  Information  Structure  as  a Key  Element  of  STIS 


STIS  Is  an  intelligence  system  and  not  a data  base  management 
system  in  the  conventional  sense.  That  is.  It  is  a specialized  tool  which 
serves  the  unique  needs  of  the  intelligence  analyst,  and  is  not  Intended  for 
generalized  use  in  maintaining  and  extracting  information  from  predefined  files. 
It  is  intended  to  adapt  to  the  variable  Information  structures  created  by 


analysts  who  view  the  world  as  a dynamically  changing  state-of-af fairs  and 
must  react  quickly  to  new  Information  requirements  and  employ  changing  strategies 
of  Information  correlation.  The  Intelligence  analyst,  as  distinct  from  his 
counterpart  in  the  commercial  data  processing  world,  must  routinely  accept  and 
maintain  conflicting  data  and  partial  information,  assess  the  credibility  of 
the  information,  and  then  use  it  to  construct  a coherent  estimate  of  a state- 
of-af  fairs. 

During  the  early  stages  of  the  evolution  of  the  STIS  concept. 


attempts  were  made  to  utilize  commercially  available  Data  Base  Management 
Systems  as  a basis  for  building  STIS.  These  early  STIS  versions  used,  or 
experimented  with,  GIS  and  FORIMS  (on  the  S/360  and  the  UlllO,  respectively), 
and  evaluated  other  Data  Rase  Management  Systems  as  well.  They  each  proved 
inadequate  to  the  task  of  serving  the  broad  spectrum  of  requirements  Inherent 


in  STI  (Scientific  and  Technical  Intelligence)  data  analysis  without  redundant 
storage  of  large  segments  of  the  data  base,  continual  definition  of  new  data 
structures,  and  redefinition  of  old  structures. 


The  approach  taken  by  the  designers  of  STIS  was  to  face  squarely 
the  variability  of  Intelligence  data,  the  need  to  accept  and  qualify  information 
on  the  basis  of  time,  source,  and  credibility,  and  the  need  to  adapt  to  multiple 
views  of  the  same  information  with  a minimum  of  redundancy  so  that  the  data 
maintenance  and  updating  problem  could  be  kept  within  bounds  of  processing 
and  storage  capability. 

They  consequently  developed  a powerful,  yet  tractable  network- 
oriented  Information  structure  that  enables  the  analyst  to  describe  a real-word 
object,  situation,  event,  or  relationship  without  being  constrained  to  some 
preconceptions  of  what  attributes  that  description  should  contain.  This  leads 
to  more  concise  data  elements  and  to  greater  adaptability  to  new  states  of  affairs. 


A major  innovation  to  be  implemented  fer  STIS  (both  for  the 
near-term  Improvement  of  STIS  1 and  for  STIS  2),  is  the  ability  to  represent 
a specified  set  of  data  values  in  a conventional  file  arrangement,  without 
the  user  being  explicitly  aware  that  this  Is  being  done.  This  technique  makes 
It  possible  to  handle  large  files  of  metric  data  in  fixed-format  records,  thus 
providing  the  high  degree  of  processing  efficiency  which  is  required  for  this 
function. 


1.2.2  STIS  Users 

The  users  of  STIS  fall  into  two  broad  categories,  on-line  and 
batch.  The  on-line  user  is  the  STI  analyst  who  wants  to  answer  an  ad  hoc  request, 
one  that  has  not  been  formalized  to  such  an  extent  that  a pre-piogrammed 
solution  for  it  exists.  He  wants  to  extract  specified  data  from  the  data  base 
to  respond  to  a Quick-Reaction  Request  or  perhaps  to  test  the  validity 
of  a new  analysis  strategy  which  he  is  attempting  to  formalize.  The  key  element 
is  that  the  on-line  user  must  Interact  effectively  with  STIS  in  ways  that 
cannot  be  completely  pre-speclfied.  He  therefore  needs  a language  for  man/ 
machine  communication  which  can  Invoke  responsive  search  and  retrieval 
routines  and  which  he  can  use  first  to  build,  and  then  to  conveniently  Invoke, 
special  sequences  of  operations  which  suit  his  analysis  tasks.  An  inter- 
active communication  mode  for  STIS  has  been  specified  and  will  be  integrated 
with  STIS  as  part  of  a Design  Optlmazation  and  Development  effort. 
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llie  batch  user  can  be  viewed  as  being  one  stage  removed  from 
direct  Interaction  with  the  machine.  He  is  buffered  from  direct  contact  with 
STIS  and  the  computer  by  a program  which  carries  out  a formalized  set  of 
analyses  and  reporting  tasks » and  therefore  the  batch  program  which  he  Is 
using  can  be  thought  of  as  providing  him  with  a specialized  interface  with 
STIS.  Prom  the  point  of  view  of  STIS,  however,  the  "direct"  user  of  STIS  in 
this  case  is  the  programmer  who  makes  use  of  the  generalized  STIS  comnands 
through  program  calls.  He  la  the  user  who  creates  the  specialized  interface 
for  the  analyst  who  can  formalize  his  requirements,  or  who  chooses  not  to 
interact  directly  with  STIS.  The  STIS  programsier-user  generally  writes  In  a 
high  level  procedural  language  such  as  COBOL  or  FORTRAN,  and  STIS  provides  a 
High-Level  Language  (HLL)  Interface  for  these  users. 


L 
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SECTION  II > THE  TECHNOLOGICAL  FOUNDATIONS  OF  STIS 

The  technological  foundations  of  scientific  and  technical 
intelligence  analysis  embrace  three  major  elements;  the  framework  within 
which  the  problem  is  viewed,  the  Information  structures  which  are  used,  and 
new  concepts  in  semantic  networks  and  knowledge-based  systems. 

2.1  THE  INTELLIGENCE  ANALYSIS  FRAMEWORK 

The  problem  of  Intelligence  analysis  has  a number  of  distinct 
features  which  set  it  apart  from  other  problems  in  data  analysis,  yet,  in  some 
of  its  aspects  it  shares  many  features  with  other  areas  of  scientific 
investigation: 


- The  facts  are,  In  general,  not  constant  in  time  but 
represent  a "snapshot"  of  a dynamic  situation,  and  the 
Influence  of  temporal  events  are  an  Important  Ingredient 
of  the  situation. 

- The  known  state-of-affalrs  Is  a result  of  observations  made 
on  the  real  world  by  imperfect  sensors  and  Is  subject  to 
equivocating  Influences,  which  produce  "noisy"  and  possibly 
Inconsistent  "facts"  as  well  as  fragmentary  or  Incomplete 
descrlptlc 'iS  of  objects  and  events. 

> Both  the  facts  and  the  rules  can  be  associated  with  a 

subjective  probability  of  truth  (credibility,  validity  or 
acceptability),  which  reflects  the  analyst's,  the  observer's 
or  the  system's  estimate  of  their  uncertainty. 

- The  analyst  is  concerned  with  the  degree  of  consistency 
of  specific  and  general  statements  (facts  and  rules),  the 
degree  of  support  (derivability  or  predictive  power)  of 
hypotheses  which  he  may  Invent,  the  uncertainty  of  source 
information  and  credibility  of  conclusions. 

The  scientist  and  the  Intelligence  analyst  are  each  often 
concerned  with  developing  a theory  which  explains  some  aspect  of  the  behavior 
of  the  real-world  domain  on  which  he  Is  focusing.  A major  difference,  of 
course.  Is  that  the  Intelligence  analyst  is  typically  concerned  with  the  de- 
scription, behavior  and  plans  of  a npn-cooperatlng  adversary,  while  the 
scientist  Is  typically  concerned  with  a system  which  is  indifferent  (but  not 
necessarily  non-roactive)  to  his  observations. 

Notwithstanding  the  above  similarities  between  Intelligence 
and  other  types  of  scientific  analysis,  there  are  distinct  differences  between 
the  two.  Relative  to  hypothesis  concept  formation  and  testing  In  most  other 
areas  of  scientific  investigation,  intelligence  analysis  often  Involves  a higher 
degree  of  uncertainty,  a lack  of  repeatability  and  control  of  experiments,  and  a 
lack  of  accessibility  of  the  subject.  There  are  also  distinct  differences  in 
the  cost,  feasibility,  and  potential  ramifications  of  observation  and  experi- 


mentation, and  the  nature  of  credibility  criteria  and  rules  of  evaluation. 


B«causa  of  these  consideretione,  the  psychology,  philosophy  end 
pereonellty  of  the  enelyst  often  enters  the  sltuetion  in  e more  direct  wey 
In  Intelligence  *;hen  in  other  scientific  Investigation.  The  intelligence 
analyst's  system  is  very  often  a personal  system,  and  is  not  easily  amenable 
to  sharing  and  interpretation  by  other  analysts.  Furthermore,  there  is  apt 
to  be  a high  degree  of  complexity  in  the  composite  factors  which  the  intelligence 
analyst  is  seeking  to  define  and  evaluate,  such  as  capability  of  the  enemy  to 
carry  out  a given  plan,  the  level  of  threat  represented  by  the  current  situation, 
the  net  balance  of  forces  or  capability,  etc. 


The  above  differences  along  with  ocher  considerations  give 
rise  to  a number  of  unique  problems  associated  with  handling  intelligence 
information.  Some  of  these  problems  and  characteristics  of  intelligence 
information  are  listed  below: 

- The  volume  of  lntelll,'',ence  information  to  be  handled  is 
high.  It  is  very  ofttn  in  non-standardlzed,  or  partially 
standardised,  format.  (Screening  and  processing  unformatted 
text  is  typically  a bottleneck  in  intelligence  systems,  and 
represents  a problem  aspect  which  is  only  partially  solvable 
by  automatic  awchods.) 

The  input  date  is  often  fragmentary.  That  is,  only  a small 
subset  of  the  possible  identifying  properties  of  the  real- 
world  entities  being  examined  or  modeled  by  the  system  are 
specified  in  a typical  input  message.  Indeed,  the  complete 
set  of  descriptive  properties  of  entities,  and  the  relations 
among  entities  which  will  be  of  interest  cannot  be  specified 
at  Che  outset,  and  rcisains  a growing  set  during  the  life  of 
the  system.  Hence  collation  of  new  information  with  previously 
scored  date  is  often  difficult,  and  can  be  accomplished  only 
In  a conjectural,  plausible,  or  probabilistic  sense. 

- Input  messages  must  be  treated  as  independent  observations 
of  a dynamic  situation,  and  therefore  it  is  isqtortant  to 
preserve  and  utilise  dateline,  source,  and  temporal  aspects 
In  the  data. 

- There  is  an  essential  problem  in  establishing  the  validity 
of  each  message  and  stored  data  item.  Thus , it  is  important 
to  associate  ancillary  information  concerning  the  source  and 
credibility  of  all  input  data,  and  some  measure  of  validity 
to  resulting  conclusions. 
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“ Processing  and  inference  rules  are  usually  not  completely 

rigorous  in  a formal  sense,  hence  it  is  important  to  consider 
them,  and  the  information  derived  by  their  application,  as 
"belonging"  to  specific  analysts,  with  specified  areas  of 
applicability,  and  levels  of  validity.  Furthermore  these 
processing  and  inference  rules  are  not  static,  hence  they 
should  be  embodied  in  the  data  base,  modifiable,  and  processed 
by  generalised  routines,  rather  than  being  implicit  in  pro- 
grammed routines  where  they  are  relatively  difficult  to  modify, 

■’  • • INFORMATION  STRUCTURES 

These  requirements  lead  to  a rejection  of  conventional  or  "pre- 
packaged" approaches  to  structuring  information.  In  particular,  the  fixed  record 
customary  in  conventional  data  processing  systems  must  be  abandoned  because 
it  is  virtually  Impossible  to  pre-deflne  a fixed  set  of  attributes  which 


are  appropriate  for  an  entity  of  a given  type.  Even  where  this  is  conceivable, 
the  highly  fragmentary  nature  of  facts  kno«m  about  a particular  entity  would 
imply  a sparse  occupancy  ratio  of  data  in  the  record,  hence  a poor  utilization 
of  storage. 

The  major  conventional  data  structuring  strategies  which  have 
been  evolving  in  computer-based  information  processing  are  called: 

a)  hierarchic, 

b)  network,  and 

c)  relational 

data  base  systems*.  There  have  been  commercial  Data  Base  Management  Systems 
based  on  each  of  these  strategies  (e.g.,  IBM's  IMS  is  basically  hierarchic; 
COOASYL's  DBMS,  or  Honeywell's  IDS,  is  a network  system;  and  General  Motors 
RDHS  is  a relational  system).  Each  has  advantages  and  disadvantages  as  tools 
for  impleatentlng  information  systems,  and  each  is  most  appropriate  for  a given 
type  of  problem  and  development  environment.  For  example,  the  chained  (link- 
sequence)  structure  within  the  record  used  in  some  data  management  systems 
(such  as  CODASYL's  DBMS)  was  rejected  because  it  Implies  a highly  sequential 
processing  of  information  (i.e.,  along  the  chain),  and  a dedication  of  space 
for  storage  of  the  linkages. 

* CJ  Date:  An  Introduction  to  Data  Base  Systems.  Addlson-Wesley , 1975 
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8TIS  solves  the  Information  structure  problem  by  representing 
sn  intelligence  entity  as  a node  In  a network-oriented  data  base.  Basically, 
a node  Is  a list  of  attribute-name/attribute-value  pairs,  where  the  value  may, 
in  general,  be  either  a single  or  multiple  occurrence  (array),  or  a structured 
sub-node.  Thus  an  n-tuple  (n-ary  relation)  Is  available  as  a special  case  of 
an  attribute  (relation)  value.  Furthermore,  a value  may  be  an  array  of 
identification  codes  of  other  nodes,  permitting,  in  effect,  any  node  to  identify 
a set  of  nodes  as  members  of  a given  relation.  This  permits  any  node  to  serve 
as  an  index  (inverted  list)  of  information  subject  to  such  powerful  retrieval 
techniques  as  set  intersection,  union,  and  difference,  and  permits  the  nodes 
thus  inter-connected  to  serve  as  an  associative  network  of  semantic  and  in- 
telligence inforatation. 

In  effect,  the  STIS  information  structure  can  be  viewed  as 
sn  amalgamation  of  the  three  data  structuring  strategies  cited  above.  Within 
the  node  it  is  hierarchic,  utllixlng  the  lack  of  redundance  characteristic  of 
that  strategy:  it  is  network-oriented  when  viewed  as  multi-node  system,  providing 
the  richly  inter-connected  access  paths  needed  in  intelligence  processing:  and 
It  also  utilises  the  formalism  of  relations  for  intemode  relationships  and 
to  provide  for  ease  of  communication  with  the  user.  (None  of  the  coosaerclally 
available  DBMS's  based  on  the  relational  strategy  allows  for  variable  (n-ary) 
relations,  a feature  unique  to  STIS.) 

In  order  to  come  to  grips  with  the  inherent  (and  unique)  character- 
istics of  intelligence  information,  the  designers  of  the  STIS  at  FTD  and  AAI 
have  chosen  a data  concept  and  data  structure  distinctly  different  from  that 
esqiloyed  in  conventional  data  processing  system. 

The  STIS  structure  which  is  used  to  store  information  for  on- 
line and  batch  users  is  called  the  Entity  Node.  Although  the  current  Entity 
Node  handles  variable  and  fragmentary  information,  it  lacks  a gene"al  capability 
to  gather,  in  a local  physical  context,  sets  of  n-ary  relationships  (n-tuples) 
and  subentitles.  To  acco^tlish  this  in  STIS.  Information  which  may  be  Iogi> 
cally  conceived  as  a single  entity  must  be  structured  as  separste  nodes  and 
therefore  be  subject  to  several  access  operations  when  retrieved  from  second- 
ary storage. 


The  ability  to  retrieve  information  by  condition  is  quite  re- 
stricted in  the  current  STIS,  being  limited  to  retrieval  under  system,  user, 
and  AOR  sets.  Different  information  structures  are  used  for  sets  and  for 
ent  i tl tes. 


The  lmprovt!d  Information  structure  to  be  Introduced  will  re- 
move these  shortcomings  In  the  near-term  and  will  be  adaptable  to  future  en- 
hancements of  STIS.  The  current  STIS  Information  structure  Is  described  in 
detail  In  Appendix  A,  and  the  new  Information  structure  is  described  in  Section 
4.  A brief  description  of  the  new  Information  structure  Is  given  below. 

The  STIS  information  structure  is  based  on  a network  of  nodes. 

The  node  is  a hierarchic  data  structure  which  brings  together  all  properties 
and  relations  which  are  associated  with  a particular  concept  (semantic  alement,  or 
entity).  A variable  for.nat  is  employed  which  nermits  storage  to  be  dedicated 
to  only  those  properties  of  the  entity  which  are  actually  known,  with  no 
space  dedicated  to  "unknown"  attributes.  Provision  is  made  for  multiple 
source  information,  with  multiple  (and  perhaps  conflicting)  values  for  a 
given  att’.'iburc.  Provision  is  also  made  for  describing  a generic,  or  "standard", 
version  of  an  entity  as  well  as  an  arbicraiy  number  of  particular  embodyments, 
and  'states",  of  particular  entitles. 

Each  node  carrier,  the  description  of  a logical  entity  or 
event.  The  description  consists  of  a variable  number  of  properties  and  is 
nrlltrai'lly  nested  with  structure  elements  representing  subentities  and 
qualifications.  The  data  nodes  are  logically  interlinked  by  attributes  which 
represent  relationships  between  entitles. 

Each  descriptive  property  consists  of  .in  attrlbutc-narae/attrl- 
bute-value  pair.  One  of  the  major  Innovations  to  be  developed  for  improve- 
ment of  STIS,  is  the  ability  of  a value  to  be  represented  by  a conventional 
^llo  and  accessed  by  a conventional  access  method,  without  the  user  being  ex- 
plicitly aware  that  this  is  being  done.  This  technique  makes  it  possible  to 
handle  large  files  of  metric  data  in  fixed-format  records  without  explicitly 
invoking  the  STIS  relational  mechanism  at  a level  where  a large  overhead  would 
be  incurred. 
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Bteause  the  STIS  entity  ie  basically  an  attributes-under-entity 
structure  and  because  access  to  the  entity  network  is  typically  conditional  by 
subject^  Area  of  Responsibility  (AOR),  and/or  attribute  value,  index  lists  of 
the  entity  network  play  a very  important  role  in  STIS.  Indexes  are  basically 
cntities-under-attribute  structures  or  "inverted"  files,  and  allow  conditional 
access  to  the  entity  network  to  be  accomplished  directly  and  efficiently,  with- 
out the  necessity  of  sequential  search  through  the  entity  network.  Whereas 
STIS  now  uses  a different  information  structure  for  the  entity  and  for  the  "set" 
or  index,  the  enhanced  STIS  uses  a common  node  structure. 

t 

In  choosing  the  STIS  node  as  the  particular  structure  to 
represent  information  ("f  's")  in  the  system,  the  designers  have  created  an 

information  structure  which  can  provide  the  following  features  and  capabilities: 


efficient  utilisation  of  random  access  (secondary)  | 

storage  for  a very  large  data  base  of  upwards  of  I 

500,000  records  I 

accommodation  of  a variable  set  of  attributes  for  the  J 

entitles  to  be  described  in  the  system  f 

quick  retrieval  of  the  facts  known  about  an  entity 

identified  by  an  arbitrary  subset  of  these  facts  | 

retrieval  of  all  entitles  having  an  arbitrary  j 

relationship  to  a given  entity,  or  which  are  members  | 

of  a given  set.  | 


easy  modification  of  the  set  of  facts  concerning  a 
given  entity 

ability  to  create  and  maintain  a vocabulary  of 
terms  and  semantic  relationships  for  effective  repre- 
sentation and  communication  of  facts  about  entitles  and 
their  membership  In  conceptual  categories  and  relations 

ability  to  qualify  facts  in  a very  general  way. 

Including  their  temporal  validity  and  relationship  to 
events,  access  control  information,  source,  credibility, 
and  relational  operators  such  as  "approximately,"  "not 
equal  to,"  etc 


- a variety  of  data  types,  Including  alphnumerlc,  text, 
and  data  (both  fixed  and  floating-point  formats) 

- an  effective  interface  to  batch  mode  application  prr grams 

- an  effective  on-line  communication  both  through  a 
generalised  user  interface  and  through  special  modes 
provide  by  application  programs 

- an  environment  for  dynamic  data  base  growth  and 
maintenance 

- controls  for  data  access  authorization  and  data  base 
protection 

- capability  to  handle  multiple  values  for  any  attribute, 
and 

- enhanced  modes  of  analyst  communication  through  textual 
annotations  such  as  warnings  and  comments. 

2 • 3 SEl^TIC  NETOORKS  AND  CURRENT  RESEARCH  TN  VNr.ULEDGE-BASED  SYSTKM 

Although  STIS  is  based  on  proven  "state-of-the-art"  technology, 
the  enhanced  STIS  data  structure  closely  resembles  the  data  structures  used  in 
advanced  research  programs  in  "semantic  networks"  and  "knowledge-based"  systems. 
Experimental  Systems  which  model  or  represent  the  state-of-af fairs  of  some 
real-world  situation  or,  more  precisely,  a human's  view  of  that  situation, 
have  been  reported  in  the  artificial  Intelligence  research  literature  for  a 
number  of  years*.  The  common  thread  running  through  these  systems  is  that 
they  allow  the  user  to  freely  describe  and  define  relationship  among  the 
entities  and  objects  which  inhabit  his  "world." 

One  of  the  largest  and  most  advanced  research  program  in 
knowledge-based  systems  is  the  Computer  Based  Consultant  (CBC)  system  being 
developed  at  Stanford  Research  Institute  under  ARPA  sponsorship.  The  CBC  is 

* A study  of  such  systems  was  conducted  by  AAI  and  reported  in  Relational  Data 
study,  RABC-TR-70-180,  September  1970,  (720263).  It  Intrudes,  for  eicemple,  e die- 

Not”  In  the  Tenth.ble  Lenguase  Comprehonder, 


d«tlgn«d  to  cotninunlcate  with  the  user  In  natural  language  and  help  him  perform 
tasks  entailing  maintenance  and  troubleoshootlng  of  electromechanical 
equipment.  The  current  test  data  base  describes  the  structure,  parts,  and 
Mintenance  of  an  air  compressor,  and  can  generate  and  execute  plans  for  assembly 
and  disassembly  at  sever, il  levels  of  detail,  and  answer  questions  about  the 
equipment  posed  by  an  apprentice.  The  system  Is  programmed  in  QLISP,  an  extension 
of  the  LISP  language  which  runs  on  the  PDP-10  under  the  TENEX  operating  system.  | 

The  data  base  of  the  CBC  Is  a semantic  net  whose  nodes  and 
attributes  have  been  divided  Into  “partitions"  forming  a partially  ordered 
set.  The  main  objective  of  partitioning  is  to  define  the  scope  of  quantlfl-  | 

cation  statements,  Tl 


The  enhanced  STIS  data  structure,  called  the  Concept  Net,  bears 
a close  kinship  to  the  type  of  semantic  net  used  In  the  CBC.  The  Concept 
Met  will  also  be  partitioned.  However,  partitions  In  the  STIC  data  base  will 
serve  additional  functions.  They  will  define  sets  of  information  which  “belong" 
to  a particular  analyst  or  Area  of  Responsibility  (AOR)  and  which  may  be  allocated 
to  separate  storage  modules  Ci.e.,  disk  packs).  Subpartitions  will  also 
Identify  sets  of  mutually  consistent  Information  (and.  In  later  phases  of 
STIS  2,  rules  and  coherent  patterns  of  fact  credibility). 
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Figure  3-1  STIS  Overall  Flow  and  Processing  Levels 


Although  for  convenience  a processor  is  shown  at  each  level,  the  levels  should 
be  thought  of  as  functions,  which  bear  no  necessary  relationship  with  modules 
of  the  system. 

3.1.1  User  Interfaces 

The  processing  of  user  calls  first  takes  place  at  the  user  Inter** 
face.  Included  among  the  functions  of  user  interface  processing  are  the  follow- 
ing; 

(1)  to  Insure  Information  base  security  and  integrity 
by  requiring  and  checking  password  and  access  rights 
Information 

(2)  to  execute  system-  or  user-specified  special  pro- 
cessing or  contingency  routines  under  appropriate 
conditions 

(3)  to  convert  data  elements  from  one  form  to  another 
(this  Includes  term  encoding  and  decoding) 

(4)  to  retain,  for  each  user,  inter-call  parameters 
and  status  Information 

(5)  to  amplify  (or  more  fully  specify)  user  calls 
through  the  incorporation  of  previously  developed 
or  specified  Informalton 

(6)  to  convert  calls  to  a common  language  or  form  for 
processing  at  the  next  level 

(7)  to  assign,  on  initial  access  by  a user,  u work  area 
to  be  used  by  STIS  for  data  base  manipulation. 

In  general,  error  conditions  occurring  at  lower  levels  in  the  STIS 
system  are  passed  back  up  to  the  user  Interface  processors.  Subsequent  pro- 
cessing depends  on  the  nature  of  the  contingency  and  on  whether  a batch  or  on- 
line user  Is  Involved. 

There  are  two  main  types  of  user  interface  processing:  batch 

and  on-line. 

3. 1.1.1  Batch 

Batch  user  Interface  processing  is  responsible  for • Interfacing 
user  programs  with  the  STI  system.  In  the  current  version  of  STIS,  and  prob- 
ably In  future  versions,  this  Interface  processing  has  two  aspects: 
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(1)  « preprocessing  phase  (currently  called  Phase  I) 

(2)  interaction  with  the  data  base  access  calls  made 
by  the  user  program  (currently  called  Phase  II) 

Phase  I generates  the  necessary  linkage  modules  for  Phase  II 
operation  by  processing  user  subroutine  calls  that  Identify  data  base  Items 
of  Interest » buffer  sizes,  and  special  processing  and  contingency  routines. 
Once  generated  by  Phase  I operation,  the  linkage  modules  are  incorporated 
Into  the  user  program  and  used  repetitively,  until  changed  conditions  re- 
quire a new  Phase  I generation. 

User  Phase  II  programs  Interact  with  the  STI  system  via  the 
linkage  modules.  In  addition  to  providing  storage  for  data  elements  and  para- 
meters, these  modules  establish  the  consnunlcation  path  with  the  Interface 
modules  that  process  the  uses  calls  under  guidance  of  those  specifications 
made  during  Phase  I operation. 

Batch  user  Interface  processing  Is  currently  oriented  toward 
programs  written  In  FORTRAN.  However,  programs  written  In  other  languages 
are  accommodated  through  Interface  programs  that  simulate  the  FORTRAN  call 
interface. 


3 . 1 . 1 . 2 On-Line 


The  on-line  user  Interface  translates  commands  expressed  In  an 
on-line  Interactive  language  into  requests  suitable  for  processing  at  the  next 
level.  As  users  sign  on  and  are  accepted  by  the  system,  they  are  allocated 
suitable  linkage  modules  to  allow  for  communication  with  the  STIS  Information 
base  facilities.  As  with  batch  processing,  these  modules  Include  space  for 
data  Items  and  parameters.  When  a user  signs  off,  or  Is  othein^lse  terminated, 
the  space  containing  his  linkage  modules  is  released 

3.1.2  Request  Decomposition 

Fully  parameterized  requests  developed  as  a result  of  user  Inter- 
face processing  are  not  necessarily  executable  as  single  requests  in  their 
current  form,  but  may  require  the  execution  of  a number  of  simpler  requests;  or 
a request  may  imply  the  execution  of  other  requests  necessary  ior  successful 
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completion.  For  example,  an  update  request  may  Imply  one  or  more  "retrieval" 
requests  In  order  to  locate  and  access  the  data  element(s)  to  be  updated.  Or, 
an  update  operation  may  also  Imply  a series  of  lower- level  retrieve  and  update 
requests  in  order  to  maintain  any  optional  Indexes  associated  with  the  updated 
data  element (s).  In  general,  the  request  decomposition  level  of  processing 
breaks  down  complex  requests  into  individual  calls  process/ible  by  lower  levels 
and  insures  that  any  implied  requests  are  executed.  All  data  access  requests 
are  executed  in  terms  of  lower  level  "create",  "update",  "retrieve"  and  "wrap- 
up"  type  requests.  Service  requests  for  STI  system  management  functions  are 
also  handled. 


The  request  decomposition  level  is  responsible  for  handling  any 
complexities  inherent  in  create  or  update  requests.  Retrieval  requests,  be- 
cause of  the  wide  range  of  potential  modes  of  analysis,  are  handled  by  a 
separate  level. 


3.1.3  Retrieval  Processing 

Retrieve-type  calls  transmitted  by  the  request  decomposition 
level  are  analyzed  to  determine  processing  requirements.  Simple  retrieve 
("get"-type)  calls  are  passed  on  without  further  processing  to  the  next  level. 

In  advanced  versions  of  STIS,  retrieval  operations  will  be  en- 
hanced by  two  additional  processors:  the  search  processor  and  the  deduction 

processor. 


If  exp'  criteria  are  to  be  applied  directly  in  the  selection 
of  data,  the  search  processor  is  called.  If  rules  are  available  for  applica- 
tion to  the  current  request,  the  deduction  processor  is  executed. 

The  search  processor  itself  can  make  use  of  intersection  pro- 
cesses and  ultimately  generates  simple  retrieval  calls.  The  search  processor 
can  also  act  as  an  agent  for  the  deduction  processor  in  performing  searches 
local  to  deduction  processing. 

3.1.4  Node  Processing 

At  the  node  processing  level,  nodes  in  the  Concept  net  and 
associated  Information  in  the  form  of  list  elements,  are  created,  maintained 
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and  retrieved.  Some  node  structures  contain  factual  Information;  others  con- 
tain semantic  Information.  All  nodes,  regardless  of  role,  have  a uniform 
structure  and  are  serviced  by  the  same  functions.  The  system  nod  functions 
are  described  In  Appendix  U. 

Node  processing  Is  concerned  with  the  packing  of  Information 
into  blocks,  the  unpacking  of  information  from  blocks,  and  the  seating,  moving 
or  copying  of  information  Although  it  detemkines  the  need  for  direct  access 
1/0  activity  and  for  the  allocation  and  deallocation  of  mass  storage  segments, 
it  does  not  actually  perform  these  functions  itself  but  gets  them  eccompllshed 
through  cells  on  the  direct  access  storage  manager. 

Sometimes  the  information  associated  with  a node  is  a collection 
of  records  on  an  external  file.  The  accessing  of  such  information  requires  the 
node  processor  to  make  sequential- type  I/O  calls  to  the  host  operating  system. 

The  value  associated  with  a given  occurrence  of  an  attribute  can 
be  specified  as  being  determined  by  the  execution  of  a pre-defined  process  which 
is  called  by  the  node  processor. 

3.1.5  Direct  Access  Storage  Management 

The  direct  access  storage  manager  responds  to  direct  access  I/O 
requests  and  to  requests  for  the  allocation  or  deallocation  of  strings  of  mass 
storage  segments.  All  requests  are  associated  with  a partition-determining 
reference  so  that  information  can  be  physically  segregated.  (Physical  parti- 
tioning is  discussed  In  Section  4,7.) 

The  storage  manager  requires  terminate  calls  from  higher  level 
processors  in  order  to  know  when  a particular  physical  partition  is  to  be 
"closed".  A closed  resident,  partition  is  opened  on  the  first  reference  to  it. 

I/O  functions  associated  with  external  storage  management  are 
delegated  to  the  Direct  Access  Storage  Manager  modules.  "Put  Node"  and  "Get 
Node"  functions  within  the  Node  Processor  perform  compression/decompression 
operations,  and  request  1/0  functions  by  generalized  calls  on  the  Direct  Access 
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Storage  nanagwr.  External  storage  to  hold  node  structures  will  be  Mslgned  in 
blocks  consisting  of  a standard  nunbar  of  consecutive  segments  (choice  of  the 
standard  number  depends  on  analysis  of  typical  node  sises  and  the  nature  of 
the  physical  loass  storage  equipment  chosen).  If  a particular  node  structure 
cannot  be  contained  within  a standard  block,  another  standard  block  is  reserved 
and  a pointer  to  the  additonal  block  is  placed  at  the  end  of  the  preceding  block. 

Buffer  space  in  core  to  hold  the  complete  standard  block  within 
the  node  processor  need  not  be  reserved.  The  nature  of  the  I/O  command^  permits 
the  working  buffer  within  the  node  processor  to  be  as  small  as  one  segment  site. 

With  respect  to  I/O  operations,  the  storage  suinager,  taking  ad- 
vantage of  Information  supplied  in  the  I/O  requests,  makes  use  of  a separate 
buffering  system  in  an  attempt  to  minimize  the  number  of  mass  storage  I/O  cells 
(and  therefore  reduce  latency  time)  by  reading^ or  writing,  with  one  call,  strings 
of  consecutive  mass  storage  segments,  rather  than  single  segments.  The  size 
of  the  buffer  pool  can  be  Independently  varied,  without  affecting  node  process- 
ing. 


Allocation  of  multi-segment  strings  takes  advantage,  where 
possible,  of  the  track  orientation  of  mass  storage  devices  so  as  to  reduce 
head  movement  time  when  the  future  corresponding  I/O  operations  take  place. 
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Example  of  User  Request  Processing 


Let  us  examine  the  way  in  which  a typical  user  req  lest  would  be 
processed  in  STIS.  We  will  assume  that  the  request  occurs  in  the  form  of  a 
command  from  an  on-line  Interactive  user  who  has  already  completed  the  slgn- 
on  procedure,  and  has  been  executing  a number  of  retrieval  and  update  commands 
on  various  network  entities.  The  flow  of  processing  Is  Indicated  in  Figure  3-2. 

The  user  command  ’’WHAT  IS  RANGE  OF  AARDVARK"  is  responded  to  by 
the  user  interface  processing  modules.  The  request  is  examined  for  syntactic 
correctness  and  completeness.  The  process  of  validation  of  the  request  (a.g., 
the  determination  that  ’’RANGE"  is,  in  fact,  the  name  of  an  attribute  and  that 
"AARDVARK"  is  an  entity  name)  is  aided  by  the  availability  of  suitable  directory 
services.  Directory  services  would  also  be  available  for  the  encoding  of  var- 
iable length  external  terms,  such  as  AARDVARK,  Into  fixed  length  internal  term 
codes. 
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Figure  3-2  User  Request  Processing  Exonple 


Afttr  validation,  tha  uaar  connand  la  raformulatad  Into  an  In* 
tarnal  font  (a.g.,  tarn  eodaa  raplaea  nanaa)  and  a call  la  aada  to  tha  naxt 
laval. 


Bafora  proeasalng  tha  current  call,  tha  raquaat  daconpoaltlon 
procaaaor  nuat  flrat  enaura  tha  completion  of  any  proceaalng  on  a pravioualy- 
accaaaad  node  which  may  have  been  auapendlng  pending  aubaequent  user  action. 

In  the  praaant  caaa,  let'a  aaaune  that,  before  the  currant  call,  tha  uaar  had 
created  aome  other  node  to  which  he  than  appended  a aarlaa  of  attribute/value 
pal'ra.  After  each  update,  the  proceaalng  atate  waa  left  In  a poature  to  re- 
ceive more  updates  for  that  node.  Uaer  reference  In  the  current  call  to  a 
different  node  now  requires  that  any  processing  associated  with  tha  created 
node  (the  currently  resident  node)  be  completed.  As  its  first  step,  then. 

In  responding  to  tha  current  call,  the  request  decomposition  level  directs 
the  node  processor  to  wind  up  processing  on  the  currently  resident  node. 

The  node  processor  must  perform  at  least  four  operations  to 
coaqtlete  processing  on  the  currant  node.  Since  It  must  output  the  created 
node  to  permanent  storage,  It  asks  the  direct  access  storage  manager  to  allo- 
cate for  this  purpose  the  required  number  of  mass  storage  segments.  It  then 
directs  the  storage  manager  to  write  the  node  data  to  the  designated  segments. 
The  Index,  or  location  table,  relating  node  identification  to  storage  location 
Is  now  updated.  The  windup  operation  is  completed  by  making  available  for  use 
all  main  memory  areas  that  had  been  assigned  to  the  processing  of  the  created 
node. 

When  control  returns,  the  request  decomposition  processor  Issues 
a call  to  locate  and  load  (l.e.,  retrieve  and  make  resident)  the  node  repre- 
senting the  entity  AARDVARK.  All  retrieve  calls  are  issued  to  the  retrieval 
analyser.  In  this  case,  the  retrieval  analyser  determines  that  the  request 
can  be  passed  through  without  further  processing  to  the  search  processor,  which 
In  turn  decides  that  it  is  a simple  retrieval  request  and  relays  it  to  the  node 
processor. 
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Th«  node  processor  determines  the  storage  location  of  the  de- 
sired node  by  searching  the  node/storage  block  Index.  If  the  search  has  been 
successful,  it  then  requests  the  storage  manager  to  read  into  owln  memory  the 
Initial  node  data  segment  and  gives  up  control  with  an  Indication  of  success- 
ful completion.  Control  eventually  returns  to  the  request  decomposition  level. 

Now  assured  chat  the  node  representing  AARDVARK  is  resident,  Che 
request  decomposition  processor  Issues  a call  to  the  retrieval  analyser  to  lo- 
cate the  RANGE  attribute  for  the  resident  node.  Without  further  processing, 
the  retrieval  analyzer  relays  the  call  to  the  search  processor,  which  deter- 
mines  that  It  is  a simple  retrieval  request  and  passes  it  inasediately  to  the 
node  processor. 


The  node  processor  steps  through  the  node  data  segments  (Issuing 
read  requests  to  the  storage  manager  for  more  data  segments,  as  required)  un- 
til it  reaches  the  information  packet  for  the  RANGE  attribute.  Control  returns 
to  the  request  decomposition  level,  with  an  indication  Chat  the  RANGE  attribute 
has  been  located.  (If  node  data  had  been  exhausted  before  locating  the  RANGE 
attribute  information,  a "no  find"  Indication  would  have  been  returned.) 

The  request  decomposition  processor  now  Issues  a call  to  re- 
trieve the  value  for  the  located  attribute.  This  simple  retrieve  call  is  passed 
through  to  the  node  processor.  Which  steps  through  the  attribute  data  until  the 
properly  qualified  value  is  found  and  returned.  (The  method  for  determining 
the  qualified  value  depends  on  whether  the  quallf icotlon  is  global  for  the  node 
or  specific  to  the  value.) 

After  successful  retrieval  of  the  value,  the  request  decomposition 
processor  returns  the  value,  with  a successful  termination  code,  to  the  on- 
line user  interface.  Here,  the  user  Interface,  aware  of  the  user’s  output  re- 
quirements, formulates  a reply  message  and  trinsmits  it  to  the  user  terminal. 
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MULTI-USER  CONSIDERATIONS 


vLdud. 


Multl-ustr  access  to  a single  resident  copy  of  STIS  will  be  pro- 


The  exact  organization  of  STIS  so  that  It  can  serve  "concurrently" 
more  than  one  user  depends  on  a large  number  of  factors,  many  of  which  are  as 
yet  undetermined.  These  factors  include: 

(a)  Physical  Equipment  and  Operating  System 

(b)  Programming  Language 

(c)  Parellellsm  of  STIS  functions 

3.2.1  Physical  Equipment  and  Operating  System 

Bssic  to  Chs  organisation  of  STIS  for  multi-user  access  Is  the 
nature  of  the  physical  equipment  configuration  and  of  the  operating  system 
services  which  support  Its  use.  These  factors  determine  the  way  in  %ihlch 
required  system  operations  and  data  can  be  distributed  among  the  hardware 
facilities,  and  define  opportunities  for  parallel  operation  and  for  queued  multi 
user  access. 


For  example,  a small  network  of  hardware  processors  and  data 
storage  devices  may  be  desirable,  In  which  one  hardware  subsystem  plays  the 
role  of  terminal  input  processor  (Including  Interactive  communication  with 
the  user),  another  subsystem  actually  executes  data  update/retrieval  functions, 
and  a third  subsystem  serves  a buf ferlng/queuing  function  between  the  other 
subsystems. 


Operating  system  services  with  respect  to  the  registration,  In- 
terlocking, queueing,  and  conditional  activation  of  activities  and  subactivities 
will  obviously  play  a crucial  role  In  the  design  of  STIS  multi-user  control. 
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3.2.2 


Ungu«i« 


Hm  protrMMing  languac*  uaWl  for  laploMneatlon  also  affaeta 
tilt  ■ulti**uaar  control  aapaeta  of  ayacaa  organlaatlon.  tha  languaga,  ehoaea 
for  aaaa  of  ioplaaantatlon  and/or  Co  enhance  cranaportablllCy»  atay  not,  for 
axanple,  provide  for  reentrant  code.  In  tha  abaenca  of  reentrant  coda,  con» 
currant  uaera  ouat  be  queued  up  to  uae  the  aarvlcea  of  single  copy  portiona 
of  Che  ayatao. 

Whether  or  not  reentrant  code  la  uaed,  a conaldarable  aaount  of 
■aln  aeaory  storage  space  aust  be  associated  with  each  active  user.  Moat  of 
this  space  Is  used  to  hold  data  segaants,  data  pointers  and  other  paraaatera 
required  for  continuity  between  calls  and  to  reduce  or  elladnate  reaccess  of 
already-accessed  inforaatlon.  The  chosen  laplonentatlon  language  aystea  aay 
allow  ST18  to  directly  access  this  Individual  user  space  (treat  It  la  Ita 
own  space)  or  It  aay  require  that  the  contents  of  user  space  be  aoved  into  and 
out  of  STIS's  own  space  for  each  user  call. 

3.2.3  Parallellsa  of  STIS  Functions 

Systea  organisation  for  aultl-user  processing  Is  affected  by 
natural  or  induced  paralllsa  (or  lack  thereof)  in  the  execution  of  STIS  functions. 
Parallisa  here  refers  to: 


(a)  the  degree  to  which  subactivities  required  to 
carry  out  a particular  user  request  can  be 
executed  independently  and  asynchronously  with 
respect  to  each  other,  or 

(b)  the  degree  to  which  the  subactivities  carrying  out 
a request  for  a particular  user  can  be  overlapped 
with  those  subactivities  serving  a request  for  a 
different  user.  For  exanple,  the  updating  of  In- 
dexes as  a result  of  an  update  operation  by 

user  A can  be  overlapped  with  the  Initiation  of 
an  update  operation  of  a different  data  item  by 
user  B. 
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3 . 3 RBCURSIVE  PROCESS ING 


While  many  of  the  control  requirements  of  STIS  are  similar  to 
those  of  other  systems,  STIS  differs  most  from  these  systems  In  Its  require- 
ment for  extensive  recursive  processing.  That  is,  recursive  processing  in  the 
execution  of  data  access  operations  is  a natural  and  primary  component  of  STIS. 
Therefore,  a considerable  portion  of  the  STIS  design  effort  is  concerned  with 
the  pushdown/ popup  stacking  of  control  ii<formation  and  data  associated  with 
such  internal  recursion. 


A requirement  may  exist  to  cope  with  external  recursion,  l.e., 
recursion  with  respect  to  the  entire  STIS  system,  where  a call  to  STIS  re- 
aulta  In  a call  to  a non-STIS  process  that  In  turn  results  In  a call  to  STIS, 
etc.  (sec  Figure  3- 3a).  This  requlresMot  can  be  net  In  one  of  at  least  two 

ways: 


(a)  On  a call  from  STIS  to  an  external  processor  or  utility 
that  may  result  In  a subsequent  call  to  STIS,  a new 
user  Identification  Is  generated  (e.g.,  by  a suffix  on 
the  original  Identification)  to  be  used  by  the  external 
processor  In  Its  STIS  calls.  STIS  treates  the  first 
call  from  the  external  processor  as  the  Initial  call 
for  a new  user,  and  assigns  a separate  work  area  to 

be  used  by  STIS.  (Of  course,  this  "new**  user  must 
satisfy  the  same  security  and  access  checks  as  the 
original  user.) 

(b)  Before  executing  a call  to  an  external  processor  or 
utility  that  may.  In  turn,  call  STIS,  STIS  records 
the  fact  that  the  system  is  In  a potential  reentry 
state  for  that  particular  user.  If  such  a reentry 
to  STIS  occurs.  It  Is  recognised,  and  appropriate 
measures  are  taken  to  allow  the  user's  current  work 
area  to  be  used  in  satisfying  the  request.  In  either 
ceso,  a stacking  mechanism  Is  required  to  retain 
certain  Information,  e.g.,  exit  address  from  STIS 
(See  Figure  3- 3b). 

Non-STIS  utilities  or  external  processors  that  themselves  are 
subject  to  recursion  during  this  process  must  contain  their  own  stacking  > :h- 
anlsms . 
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Figure  3-3 (b)  Multi-Level  Recurulon  end  Stacking 


SECURITY  PROCESStHG 


taeurity  procttatini  within  8TI8  1*  concai'ncd  with  th«  protection 
of  tho  data  boat  froa  illa|itlnata  acrutiny  and  from  uneentrollad  aodlfleatlon 
or  daatructlon.  Aa  In  all  aueh  ayatana,  auch  aoeurlty  procnaaing  funetlona  at 


a«.varal  lavala. 


At  the  outaraoat  laval.  only  certain  teralnala,  or  teralnal  groupa, 
are  permitted  acceae  to  8TIS,  and  the  funetlona  allovable  to  any  particular  ter- 
minal are  atrlctly  defined  by  tho  ayatoma  manager.  At  the  next  level>  uaer  paaa- 
vorda  are  aaaoclated  with  a particular  Area  of  Reaponalblllty  (AOR)i  ao  that  the 
AOR  code,  which  la  the  key  to  further  acceaa,  can  only  be  Invoked  by  legitimate 
uaera.  At  the  next  level,  the  AOR  code,  through  roatrlctlon  to  a particular 
partition  and/or  fact  qualification,  llidta  acceae  to  certain  data,  and  alao 
protecta  that  data  from  unpermltted  acceaa  by  other  AOR* a. 


All  aueh  aecutlty  procedurea  are  governed  by  ay atom  tablea 
acteaalble  only  to  the  ayatem  manager,  end  by  the  methoda  of  fact  qualifica- 
tion built  Into  the  ayatem. 


SYSTEMS  MANAGEMENT  FUNCTIONS 


Syatema  management  capabllltlea  In  STIS  are  intended  to  serve 
two  main  funetlona: 


(a)  Supervisory  control  of  uaer  acceaa  criteria 

(b)  Overall  control  of  data  baae  dlatrlbution  and 
availability 


3.5.1 


User  Access 


Functions  are  provided  to  the  systems  manager  to  allow  for  the 
entry,  modification  and  deletion  of  entries  In  user/termlnal/paasword/access 
rights  tables  In  STIS.  The  systems  manager  can  add  or  delete  terminals  or 
terminal  groups,  or  change  the  access  privileges  of  existing  terminals.  He 
can  add  or  delete  specific  users  or  change  their  access  rights.  The  systems 
manager  can  display  or  print  any  InforsMtlon  appearing  In  such  systems  tables ■ 
including  user  statistics.  If  they  are  maintained. 


3.5.2  Data  Base  Distribution 

The  systems  manager  has  facltltles  to  allov  for  the  definition 
of  data  base  partitions,  the  movement  of  partitions  on  and  off  line,  and  the 
temporary  disabling  of  partition  access  (see  Section  4,7).  He  maintains 
the  configuration  of  available  partitions  based  on  normal  usage  requirements, 
and  has  the  means  to  create  special  configurations  to  meet  temporary  emergency 
needs. 
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SECTION  IV.  THE  CONCEPT  NET  — A 
NEW  INFORMATION  STRUCTURE  FOR  STIS 


4.1  A MODEL  FOR  INTELLIGENCE  INFORMATION 

The  Concept  Net  represents  the  intelligence  analysts'  collective 
view  of  the  current  state-of-af fairs  in  the  real  world.  It  is  populated  with 
"facts"  distilled  by  the  analyst  from  observations,  reports  of  observations,  and 
assertions  concerning  his  sphere  of  interest  in  that  world.  Since  it  is  a dy- 
namic world  and  viewed,  as  it  were,  "through  a glass,  darkly",  each  fact  has 
associated  with  it  an  open-ended  set  of  qualifying  statements  which  Include, 
typically,  the  source  (or  message)  from  which  it  was  derived,  its  interval  of 
validity  (in  time  and/or  space) , the  date  of  observation  or  entry  into  the 
system,  the  credibility  (probabilistic  truth  value)  assigned  by  the  analyst, 
and  the  time-constant  (or  "half-life")  which  characterizes  the  volatility  of 
the  information.  Because  virtually  all  Intelligence  information  is  both  of 


questionable  veracity  and  subject  to  change,  we  view  the  original  credibility 
level  as  being  modulated  by  an  exponentially  decaying  weighting  function 
whose  time  constant  is  characteristic  of  the  volatility  of  the  type  of  infor- 
mation in  question.  For  example,  the  place  of  employment  of  an  Individual 
may  have  a half-life  of  four  years.  That  is,  if  it  was  reported  in  1970  that 
George  Murphy  worked  for  RCA,  and  this  "fact"  was  accepted  with  a credibility 
of  0.8,  then  in  197A,  in  the  absence  of  any  new  data  concerning  Mr.  Murphy, 
the  credibility  of  that  fact  would  be  O.A. 

Another  characteristic  of  intelligence  information  is  that  there 
may  be  conflicting  reports  concerning  the  facts  about  a given  entity  and/or 
legitimately  differing  views  among  one  or  more  analysts  as  to  what  the  facts 
may  be,  or,  for  that  matter,  more  than  one  value  for  a given  attribute  may 
be  valid  in  a given  time  interval.  (The  case  may  be  that  Mr.  Murphy,  while 
working  for  RCA,  moonlights  as  an  instructor  for  Rutgers  I'niverslty  so  that 
apparently  conflicting  reports  on  Mr.  Murphy's  occupation  may  be  reconcilable, 
and  coexist  with  a high  credibility.  On  the  other  hand,  the  report  of  Mr.^Iurphy's 
employment  at  Rutgers  may  be  a deliberate  plant  or  "cover"  to  obscure  the  fact 
that  he  works  for  RCA.)  Far  this  reason,  and  to  provide  for  simultaneous  use 
of  a common  body  of  information  among  many  analysts,  the  analyst  or  organization 
which  is  responsible  for  a given  "fact ' is  recorded  as  part  of  the  information 
qualifying  that  fact. 


A. 2 THE  CONCEPT  NODE 

The  Concept  Net  is  organized  as  a network  of  nodes,  each  of  which 
represents  a concept  (such  as  an  individual  or  other  entity)  which  is  of  Interest 
to  the  analyst.  The  node  in  turn  contains  a set  of  facts  (properties)  made  up 
of  attribute  names  and  qualified  values,  which  describe  the  entity  and  its  re- 
lationsh:!ps  to  other  entitles.  These  facts  are  derived  from  (and  tied  to) 
messages  concerning  observations  of  the  real-world.  Other  nodes  may  represent 
concepts  which  exist  independently  of  messages  (or  observations  of  the  world) 
such  as  semantic  concepts  representing  the  attributes  and  values  themselves, 
as  well  as  their  inter-relationships.  (Value  nodes  will  also  be  related  to 
the  entitles  which  are  described  by  (or  use)  those  values,  providing  a cross- 
index  to  the  Entity  Net.) 
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Each  node  in  the  Concept  Met  comprisea  an  open-ended  set  of 
properties  of  the  concept  or  real-world  entity  which  is  represented  by  the 
node.  A property  is  an  attribute-naae/attrlbute-value  pair  which  nay,  in 
turn,  be  qualified  by  an  arbitrary  list  of  properties.  Attributes  and  values 
(also  tenas  and  words)  are  themselves  represented  by  nodes  in , the  Concept  Net. 

An  entity  node  may  stand  for  a real-world  individual,  unit,  facility,  weapon, 
event,  etc.  A node  may  also  represent  a state  it  sub-entity  attached  to  a 
parent  node.  For  example,  a parent  node  may  represent  a generic  class  of 
weapons,  such  as  the  Minuteman  missile,  while  a sub-node  may  represent  a specific 
example  of  that  missile  Installed  at  a particular  site,  with  a particular  target, 
etc. 


When  a gjLven  entity  or  other  concept  node  (the  source)  bears 
some  relationship  to  another  concept  node  (the  target),  that  relationship  is 
represented  in  what  is  called  an  entity-relational  attribute  in  the  source  node. 
Its  value  is  the  identifier  (Node  /*)  of  the  target  node.  In  order  to  provide 


complete  cross-referencing,  there  will  be  defined  for  each  relational  attribute 
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R (using  its  Attribute  Node  in  the  Semantic  Net)  an  Inverse  relation  R so 


that  if  entity  a bears  relation  R to  entity  b "R(a  b)”  then  entity  b bears  re- 
lationship r”^  to  entity  a "R~^(b  a)".  For  example,  if  the  Pershing  Missile 


has  a test  site  at  White  Sands  "Has  Test-site  (Pershing  Missile,  White  Sands)", 
then  White  Sands  is  the  test  site  of  the  Pershing  Missile  "Is  test-site  (White 
Sands,  Pershing  Missile)"  where  "Inverse  (has  test  site,  is  test  site)" 

and  "Inverse  (is  test  site,  has  test  site)".  In  the  above  example,  the  first 
two  statements  would  be  in  the  Entity  Net  (Pershing  Missile  and  White  Sands 
nodes,  respectively)  while  the  latter  two  statements  would  be  in  the  Semantic 
Net  (Has  test  site  and  Is  test  site  nodes,  respectively). 


In  addition  to  entity-relational  attributes,  an  entity  may 
possess  attributes  whose  values  are  names,  numbers,  or  descriptive  terms 
which  are  not  other  entitles.  These  values  may  be  represented  by  nodes  in 
the  Semantic  Net  (rather  than  the  Entity  Net)  which  in  turn  cross  reference. 
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as  entity  (ni  iri  .)  lists,  those  entities  which  use  them.  Hence,  the  dls- 
I tinctlon  betwfei;n  entity-relational  and  non-entlty-relational  attributes  has 

V I little  operational  significance  for  search  strategies  in  the  system.  In 

I either  case,  the  entitles  possessing  a given  property  are  accessible  through 

the  cross-referencing  (indexing)  feature,  whether  it  be  the  node  representing 
f s the  target  of  an  entity-relational  attribute  or  the  node  (in  the  Semantic  Net) 

‘ representing  the  value  of  a non-entlty-relational  attribute.  The  entity  list 

under  the  value  node  can  be  considered  the  inverse  of  the  non-entity  relational 
I'  attribute  in  the  entity  node  in  which  it  occurs.  The  Concept  Net  provides  for 

t both  an  attrlbutes-uhder-entity  (normal  file)  and  an  entitles-under-attribute 

(Inverted  file)  point  of  view.  This  redundancy  of  access  path  — sacrificing 
space  for  time  — is  built  by  the  system,  under  control  of  the  Data  Base 
Administrator  (who  may  limit  this  redundancy  selectively)  and  need  not  concern 
the  analyst  who  chooses  to  limit  his  role  to  that  of  an  information  consumer. 


SUB-NODES  — COMPOSITE  ATTRIBUTES  AND  N-TUPLES 


There  will  be  instances  in  the  Concept  Net  when  it  will  be  use- 
ful to  consider  one  node  as  subordinate  to  another  in  a hierarchic  sense  (rather 
than  the  non-hlerarchlc,  or  coordinate,  relationship  between  two  nodes  which 
are  joined  by  an  entity-relational  attribute).  When  this  subordinate  relation- 
ship is  defined,  it  implies  the  desirability  to  store  the  subordinate  node  so 
that  it  is  physically  accessible  with  the  parent  node,  reflecting  logical  de- 
pendency and/or  predictable  access  patterns.  When  this  occurs,  the  subordinate 
node  is  called  a sub-node  of  the  parent,  or  master,  node. 


■ 


The  sub-node  relationship  can  arise  in  several  contexts.  In 
addition  to  the  close  master/slave  relationship  that  may  exist  between  two 
entitles,  mentioned  above,  a subnode  may  represent  what  is  called  a composite 
attribute,  or  n- tuple.  A composite  attribute  is  an  attribute  comprising  a 
set  (n-tuple)  of  simpler  attributes.  For  example,  position  may  be  defined  as 
a composite  attribute  comprising  the  simple  attributes  latitude  and  longitude, 
or  address  comprising  number,  street , city,  and  state.  Composite  attributes 
provide  for  generic  terms  which  conveniently  reference  and  retrieve  a set  of 
specific  information.  The  analyst  or  programmer  who  is  concerned  about  the 
structure  of  the  Concept  Net  or  is  developing  appropriate  terminology  for 
semantic  concepts  may  work  with  the  Data  Base  Administrator  to  define  composite 
attributes  or  other  sub-node  relationships. 


FORMAL  DESCRIPTION  OF  THE  CONCEPT  NODE 


f:: 


Each  Concept  Node  in  the  STIS  Concept  Net  Is  represented  by 
the  same  formal  structure,  called  a description  list.  Entity  Nodes,  Attribute 
Nodes,  and  Value  Nodes  are  all  Instances  of  Concept  Nodes  In  STIS.  Each  Con- 
cept Code  (or  Node  ft)  Is  the  name  of  a description  list.  (The  Node  9 will  be 
used  as  a key  to  obtain  the  description  list  from  permanent  storage.)  Sub- 
nodes are  also  represented  by  description  lists  but  they  do  not  have  separate 
Concept  Codes  assoclat'  with  them  since  they  are  stored  with  the  parent  node. 
A composite  value  (the  valr.c  of  a composite  attribute)  is  a special  case  of  a 
sub-node  in  which  the  attributes  have  been  predefined. 


A Concept  Node  in  STIS  is  a description  list.  The  formal  syn-  j 
tax  of  a description  list  is  specified  in  Table  4-1.  Lower  case  letters  repre-  | 
sent  syntactic  variables  and  upper  case  letters  represent  concept  codes  or  .1 
other  terminal  atomic  symbols.  | 

•l! 

There  is  no  syntactic  distinction  between  brackets  and  paren-  | 
theses.  Note  that  a description  list  is  defined  recursively  so  that  there  I 
is  no  constraint  on  the  nesting  of  subnodes  representing  qualifiers  or  com-  | 
posite  values. 


4.5  THE  SEMANTIC  NET 

The  Semantic  Net  is  that  subset  of  the  Concept  Net  comprising 
Attribute  and  Value  Nodes.  All  attributes  and  values  are  represented  by  nodes 


in  the  Semantic  Net.  (In  the  case  of  numeric  values,  the  Value  Node  represents 
an  interval  on  a lograrlthmlc  or  linear  scale.)  When  they  occur  in  the  descrip- 


TABLE  4-1 


NODE  STRUCTURE  SPECIFICATION 

Note:  The  convention  used  here  for  syntax  specification  uses  the  following 

metalinguistic  symbols: 

^ Is  defined  as,  or  can  be  replaced  by 

^ ) one  or  more  occurrences  of  the  expression  enclosed 

by  the  lower  half-bracket 

I choice  symbol 

f ^ optional  (at  most  one  occurrence)  of  the  expression 

enclosed  by  the  upper  half-brackets 


Syntax 


deslist  *■ 

(0  tpropj] 

prop  *■ 

(A  val) 

val  •♦•V  1 [»^valj]  1 (val  qual)  | deslist 

qual 

t*  :.propj) 

Semantics 

deslist  * 

description  list 

prop  - 

property 

val  - 

value 

A - 

Attribute  Code  (i.e..  Node  (f) 

V - 

Value  Code  (i.e.,  Node  numeral,  or  string 

representing  a terminal  value. 

qual  " 

qualification  list 

tv  ...1  - 

array  (list)  value 

(val  qual)  ■ 

a qualified  value;  qual  is  the  subnode  which 
qualifies  val 

(A  deslist)  >■ 

a composite  property;  A Is  the  composite  attribute 
and  deslist  is  the  sub-node  representing  the  composite 
value. 
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TABLE  A-1  (Continued) 


Examples 

The  following  description  list  examples  represent  Entity  Nodes 
In  the  interest  of  clarity,  attribute  and  value  names  are  used  rather  than 
Node  Numbers. 

Pi  ■ [@(Name  [@(First  Jerry)  (Last  Sable)]  ) (Age  (45  [*(Source  Est) 
(Accuracy  ± 3)  (Validity-interval  1975)])) 

(Works-at  #2)] 


•V  t@(Name  AAI)  (Fac-type  Consultant-org)  (Employs  [PI  P3  PU]) 
(Location  ([Phlla  Wash]  (*(Cred  0.90]))] 

#3  ■ ([(?(Name  Schernecke)  (Works-at  //2)]  [*(A0R  Consultants)]) 

» ([@(Narae  McCrea)  (Works-at(//2t*(Valldity-interval  [1963  1975])]))] 
[*(A0R  Consultants)]) 
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4.5.1 


Attribute  Nodes 


The  description  of  any  concept  consists  of  a list  of  properties, 
l.e.,  attribute  name/value  pairs.  Since  attributes  are  concepts  themselves, 
they  are  represented  by  nodes  in  the  Semantic  Net  subset  of  the  Concept  Net. 

Some  of  the  attributes  which  can  be  expected  to  be  used  in  the  description  list 
of  an  Attribute  Node  are  listed  below.  (It  should  be  noted  that  as  in  all  nodes, 
these  attributes,  except  when  they  are  self-referencing,  are  represented  by  the 
Node  Codes  of  Attribute  Nodes.  Their  values  are  represented  either  by  Node 
Codes  or  by  Term  Codes.) 

Attribute  name 

Synonyms 

narrower  attributes  (for  composite  attributes) 

Broader  attributes  (for  components  of  composite  attributes) 

Inverse  attribute  (for  Entity  Relational  attributes) 

Values  (the  list  of  values  for  this  attribute,  limited  to  the 
first  domain  element  in  the  case  of  Entity  Relational 
attributes) 

Attribute  Data  Information  — the  value  of  this  attribute  is 
a pointer  to  the  Attribute  Data  Record  in  a Direct 
Access  file  outside  of  the  Concept  Net.  The  ADR  de- 
fines the  format,  precision,  units,  and  "owner"  of 
the  attribute.  This  is  an  example  of  a special  attri- 
bute, or  Process  Hook,  which  invokes  an  outside  routine 
to  compute  a complex  value,  using  the  nominal  attribute 
value  as  a parameter. 

Other  Attribute  properties,  such  as  transitivity,  reflexivity, 
and  symmetry  which  may  exist  will  also  be  represented  in  the  property  list  of 
the  Attribute  Node. 


4.5.2 


Value  Nodes 


Each  non-numeric  value,  or  range  of  numeric  values,  which  can 
serve  as  a retrieval  condition  will  be  represented  as  a Value  Node  in  the 


. 
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Concept  Net.  When  indicated  by  the  analyst*  or  Data  Administrator,  the  Value 
Node  will  serve  as  the  head  of  an  Index  to  Information  In  the  Entity  Net. 

This  provides  support  for  the  three  basic  strategies  for  retrieving  informa- 
tion about  Intelligence  entitles: 

(1)  through  the  context  of  an  explicitly  identified 
entity,  including  its  association  with  other 
entities  via  relational  attributes, 

(2)  through  a retrieval  criterion  made  up  of  a set 
of  specified  properties  whlcb  the  entity  should 
possess,  and 

(3)  through  properties  which  are  plausible  for  the 
entity  because  they  can  be  inferred  from  general- 
ized rules  stored  in  the  Concept  Net. 

Some  of  the  attributes  which  can  be  expected  to  be  used  in  the 
description  list  of  a Value  Node  are  listed  below: 

Value  name 

Synonyms 

Narrower  values  (or  subsets) 

Broader  values  (or  supersets) 


Attribute  (the  attribute  that  has  this  node  as  a value,  the  in- 
verse of  the  Values  attribute  in  the  Attribute  Node) 

Entitles  (the  entitles  which  have  this  node  as  a value.  This 
serves  as  the  index  list  for  those  entities.) 


4.6.  THE  ENTITY  NET 

Information  about  any  incelllgence  entity  of  concern  to  the 
analyst  can  be  stored  in  STIS  by  creating  an  Entity  Node  to  represent  it  in 
the  Concept  Net.  Once  the  node  is  created,  the  description  of  the  entity  is 
storoid  as  a list  of  properties.  Internally,  the  entity  la  known  by  its  Node 
Numbtir,  which  serves  as  its  retrieval  key  from  permanent  storage,  as  is  the 
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CMt  for  any  nod*  in  th*  Concept  Hot.  In  it*  aimplost  fora,  th*  ontity 
nuabor  n is  r*pr*8*nt*d  by  * d**eription  list  fuoh  *•: 


Ce  (A  •)  (B  b)  (C  c)  ...] 


The  interpretation  ie  that  the  entity  represented  by  node  n has  ell  of  th* 
properties  listed*  That  is,  in  conventional  relational  or  logical  foraat, 
the  attributes  A,  B,  C,  ...  are  binary  relations  connecting  the  entity  and 
a value  and  the  following  conjunction  holds: 


A(n,a)  A B(n,b)  A C(n,c)  A ... 


Thus,  in  the  Entity  Net,  inforaation  is  collected  in  an  "attri- 
butes-under-entity"  format,  while  in  the  Semantic  Net,  one  may  say  that  the 
same  informatioii  appears  in  an  "entities-under-attribute"  format.  As  will  be 
discussed  below,  the  simple  description  list  form  can  be  generalised  in  a 
number  of  important  ways. 


4.6.1 


Entity  Relations 


The  simplest  relations  are  attributes  which  take  scalar  values, 
either  literal  or  numeric,  such  as  Naroe(n, Atlas)  and  Weight (n, 150) . However, 
values  are  generalized  to  permit  arrays,  such  as  Name (n, [Atlas, H12])  and 
Locatlon(n, [ND,FL]) . Assuming  Node  n is  #10,  this  would  appear  in  description 
list  fprmat  as: 


#10  - [@(Name  (Atlas  H12])  (Weight  150)  (Location  [ND  FL])  ] 


Entity-relational  attributes  name  other  Entity  Nodes  as  values. 
If  entitles  #11  and  #12  were  test  sites  for  #10,  then  the  update  command  "Add 
Test-Site  (#10,  [#11,  #12])"  would  add  the  property  (Test-Site  [#11  #12])  to 
the  description  list  for  #10. 


■ 
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By  ptmittlng  a valut  to  b«  tcpreicntad  by  a daacription  Hat, 
or  aubnodoy  tha  daacrlptlva  powor  of  tb*  tyatan  la  augmantad  In  a nuabar  of 
vaya.  The  almplest  inatance  of  thist  the  compoaite  attribute,  van  deacrlbed 
In  Section  3.  Other  caiea  will  be  dlacuseed  In  the  following  paragraphs. 

A. 6. 2 Generic  Entitles 

It  is  often  useful  to  describe  an  object  as  a generic  type  for 
which,  in  the  real  world,  there  exists  a number  of  specific  occurrences.  This 
can  be  done  by  creating  a node,  called  a generic  entity,  which  represents  the 
coaaK>n  characteristics  for  these  objects.  Tliis  can  then  be  supplemented  by  a 
node  for  each  individual  object  for  which  specific  information  is  required  but 
which  is  not  characteristic  of  the  class  as  a whole.  For  example,  suppo''>e  we 
have  the  missile  type  Atlas  represented  by: 

120  • (((System  ICBM)  (Name  Atlas)  (Weight  150) 

(Accuracy  3)  (Instances  [f21  #22  123])  ] 

Nodes  #21,  #22,  and  123  then  are  specific  entities  whose  general  characteristics 
are  given  in  node  #20  and  therefore  may  be  inferred  by  reference  and  need  not 
be  explicitly  repeated.  Each  instance  will  reference  the  generic  entity  and 
give  only  unique  characteristics,  such  as: 

#21  ■ (((Location  ND)  (Target  #31)  (Serial  1234)  (Generic-entity  #20)] 
Note  that  the  attributes  "Instances"  and  "Generic-entity"  are  a converse  pair. 
4.6.3  Entity  States 

It  is  often  necessary  to  track  changes  in  a given  set  of  proper- 
ties of  a specific  object.  To  do  this,  subnodes  called  "states"  are  created. 

The  relationship  between  a specific  entity  and  a state  of  that  entity  Is  paral- 
lel to  that  between  a generic  entity  and  a specific  entity.  That  is,  only  pro- 
perties whose  'alues  change  from  one  state  to  the  next  need  be  recorded.  In- 
var lent  properties  are  given  in  the  parent  node.  For  example,  suppose  a Polaris 
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type  tubmarin*  is  being  tracked.  Intermittent  reports  of  its  location  may  be 
given  in  state  nodes  which  reference  the  specific  entity  node.  The  specific 
entity  node  may,  in  turn,  reference  a generic  entity.  This  interrelationship 
of  subnodes  is  diagrammed  in  Figure  4-1. 

The  recurring  motive  for  introducing  subnode  relationships  such 
as  "instance"  and  "state"  is  to  avoid  redundant  storage  of  information.  The 
payoff  for  eliminating  unnecessary  redundancy  is  reduction  of  maintenance  and 
retrieval  time  as  well  as  space.  Storage  compression  at  the  state  level  can 
be  carried  to  a further  stage  when  changes  in  state  are  predictable  or  can  be 
represented  analytically  as  a function  of  time.  Opportunities  for  this  may 
exist  in  situations  such  as  when  a periodic  Itinerary  for  a submarine  or  other 
ship  is  known,  or  when  a satellite  position  may  be  found  from  orbital  parameters 
rather  than  extrapolation  or  interpolation  of  tracking  data.  In  such  cases, 
state  nodes  may  be  replaced  by  compact  state-transition  information. 

4.6.4  Fact  Qualification 


It  is  possible  to  modify  or  qualify  information  by  appending 
a qualification  list  to  either  a description  list  (node  or  subnode)  or  a value. 
The  qualification  list  has  the  format  of  a description  list  so  that  the  two 
forms  arc  respectively  (desllst  qual)  and  (val  qual)  where  the  second  element 
is  the  qualification  list.  Typically,  qualification  information  in  an  Entity 
Node  will  contain  fact  control  (access  control)  information  if  it  is  at 
the  node  level  and  fact  control  and/or  source,  credibility,  and  temporal  data 
at  the  value  level.  Because  information  may  be  obtained  from  several  sources 
and  may  be  varying  with  time,  multiple  values  will  be  common  in  the  Entity 
Net.  The  particular  values  which  are  valid  for  a given  analyst  at  a given 
time  will  be  determined  on  the  basis  of  the  qualification  list. 

The  default  interpretation  of  the  jproperty  (A  v)  for  an  entity 
(say  e)  la  that  the  entity  has  the  value  v for  the  attribute  A.  In  symbols  A(e) 
■ V.  The  value  v may  either  be  a scalar  V or  an  array  [V...].  However,  there 
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are  occasions  when  one  wants  to  specify  a relational  operator  other  than  equality 
between  the  attribute  and  the  value.  Possible  relations  are  greater-than,  less- 
then,  not-equal,  approxlmately-equal,  not-grca ter- than,  etc.  The  qualification 
list  is  also  the  mechanism  for  accomplishing  this,  with  the  exception  operator 
attribute  "Rel-op".  For  example,  Age(e)>40  would  be  given  as  (Age(40(*(Rel-op  >)])). 


4.6.5  Computed  Values 

There  will  be  Instances  when  It  is  more  convenient  to  compute 
a value  for  a given  attribute  from  specified  parameters  rather  than  explicitly 
Store  Its  value.  This  will  be  especially  true  for  large  arrays  of  composite 
attributes.  For  example.  It  will  often  be  more  efficient  to  compute  the  posi- 
tion, velocity,  acceleration,  etc.  of  a missile  from  trajectory,  atmospheric 
and  vehicle  parameters  rather  than  store  explicit  values  with  the  required 
precision.  Even  where  analytic  computation  Is  not  practical,  it  Is  often 
more  efficient  to  store  values  in  large  dense  arrays  or  conventional  files 
(on  serial  or  random  access  storage)  and  provide  the  appropriate  file  name 
or  key  In  the  description  list.  Another  example  of  the  latter  situation  Is 
the  Fact  Control  Information  required  for  most  entitles  and  properties.  Be- 
cause this  data  can  be  readily  formatted  into  fixed  files,  it  may  be  more 
efficient  to  provide  a key  to  a Fact  Control  Data  File  in  the  qualification 
list  pertinent  to  the  basic  information,  rather  than  provide  that  data  In 
description  list  format. 

This  capability  will  be  accommodated  by  using  a special 
"Process-Hook"  symbol  and  parameter  list  In  place  of  the  actual  value  In 
the  description  list.  The  retrieval  mechanism,  when  encountering  the  Process 
Hook,  will  invoke  the  specified  program  and  supply  the  given  parameters.  The 
called  program  will  return  the  required  value. 

4.6.6  Quasl-transltlve  Relationships 

The  use  of  entity  relational  attributes  In  the  description  of 
the  various  objects  of  Interest  to  the  analyst  results  In  a network  of  nodes 
In  which  information  Is  highly  associated.  This  richness  of  association 
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permits  Information  to  be  retrieved  from  many  points  of  view  or  search  paths. 
Although  this  feature  Is,  In  general,  desirable,  unless  special  precautions 
are  observed,  there  are  situations  In  which  It  can  lead  to  the  retrieval  of 
Information  which  does  not  validly  meet  the  conditions  specified  by  the  in- 
terrogator. 

Consider,  for  example,  a situation  In  which  a weapon  platform 
(say  a fighter-bomber)  can  be  equipped  to  bear  either  of  two  types  of  arma- 
ment (say  torpedo  or  Incendiaries)  depending  upon  under  which  service  unit 
(aircraft  carrier  or  tactical  air  base)  It  is  employed.  A given  entity  re- 
lational attribute  (such  as  "uses")  may  be  used  to  enter  this  Information: 


Uses  (Carrier  Lexington,  F-11) 

Uses  (F-11,  torpedos) 

Uses  (TAG  Ease  Charlie,  F-11) 

Uses  (F-11,  incendiaries) 

The  five  entities  would  then  be  interconnected  with  the  "Uses"  relation  as 
shown  in  Figure  4-2.  It.' is  apparent  that  a request  for  armament  used  by  the 
Carrier  Lexington  (or  TAC  Base  Charlie)  aiay  come  up  with  the  erroneous  answer 
"Incendiaries  and  torpedos".  The  fallacy  is  caused  by  what  can  be  called  a 
"connection  trap"  in  the  F-11  "hub"  of  the  network.  It  is  avoided  by  using 
one  or  both  of  the  following  devices; 

(1)  The  set  of  values  of  a multivalued  attribute  are 
qualified  to  Inform  the  system  that  only  one  of 
the  values  can  occur  In  each  instance. 

(2)  A configuration  node  (or  subnode)  is  created  to 
describe  each  valid  configuration  of  properties. 

These  approaches  are  detailed  below. 

Since  an  attribute  may  have  an  array  as  a value,  we  can  have 
a property  such  as: 

(Armament  [torpedo  incendiary]) 

in  the  description  list  for  an  entity  (say  F-11).  This  raises  the  question  as 
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to  the  Interpretation  of  the  array: 


V - t Vj^  Vj  . . . J 

when  it  occurs  as  a value.  The  members  may  be  an  ordered  n-tuple,  an 
(unordered)  set,  a bag  (unordered  sec  In  which  repetitions  are  permitted),  a 
disjunctive  set  (any  subset  is  valid),  a conjunctive  set  (all  values  co-occur), 
or  a choice  set  (only  one  value  is  valid  in  each  instance).  The  type  of  set 
which  is  Intended  can  be  identified  by  using  the  attribute  "Set-type"  in  a 
qualification  list  for  the  value.  For  example: 

(Armament  ([torpedo  incendiary]  (*  (set- type  choice)  ])  ) 

The  use  of  the  "Set-type  choice"  qualifier  alerts  the  system 
(and  the  user)  that  only  one  value  is  valid  but  in  Itself  is  not  sufficient 
to  specify  which  Is  the  valid  value  in  a specific  case.  This  problem  can  be 
solved  by  using  a subnode  (or  a state)  of  the  entity  to  establish  a description 
of  each  configuration  of  the  parent  entity.  For  example,  ve  nan  have  the  states 


and 


(@(Used-by  Carrier-Lexington)  (Armament  torpedo)  ] 


[@(Used-by  TAG  Base  Charlie)  (Armament  incendiary)  ] 


under  the  generic  entity  for  the  F-11.  Note  that  this  second  approach  avoids 
the  multiple  values  attribute  and  is  sufficient  in  itself  to  unambiguously 
describe  the  situation. 


4.6.7  Footnotes 

The  analyst  entering  facts  Into  the  Entity  Net  will  be  permitted 
to  qualify  any  value  (or  entity)  with  unformatted  comments,  warnings,  or  other 
text.  He  simply  labels  this  text  (genetically  called  footnotes)  with  the  appro- 
priate attribute  (Comment,  Warning,  etc.)  and  enters  it  with  other  qualification 
information.  Rather  than  store  unstructured  text  as  part  of  the  node,  a special 
use  will  be  made  of  the  Process  Hook  capability.  The  value  of  the  specified 
attribute  will  be  a pointer  to  the  appropriate  record  In  an  external  Foot  note 
File.  The  footnote  will  be  retrieved  automatically  with  other  qualification  in- 
formation whenever  required. 
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4.7 


CONCEPT  NET  PARTITIONS 


Each  fact  or  node  In  the  Concept  Net  will  belong  to  some  sub- 
space of  the  Concept  Net  called  a partition.  Partitions  will  form  a lattice 
or  partial  ordering  so  that  a given  partition  may  in  turn  contain  other  par- 
titions. The  objectives  of  partioning  the  Concept  Net  are  as  follows: 

(1)  to  establish  sets  of  information  (at  the  highest 
level)  which  should  coexist  on  the  same  level  of 
physical  storage  because  of  access  patterns  or 
ownership  (Areas  of  Responsibility), 

(2)  to  establish  sets  of  mutually  self-consistent  (or 
"coherent")  facts,  rules,  and  credibility  measures. 


(3) 


to  establish  a space  in  which  facts  form  a set 
of  homogeneous  type,  such  as  and , or,  nand (not-and)  , 


choice,  etc. 
of  a set, 


i.e.,  to  establish  the  scope  and  semantic 


(4)  to  establish  the  scope  of  quantification  in  general 
statements  or  rules. 


The  partition  to  which  a fact  belongs  will  be  Identified  as  a 
property  In  Its  Qualification  List.  When  all  the  facts  in  a given  node  (or 
subnode)  belong  to  the  same  partition  It  may  be  "factored  out"  to  become  a 
property  at  the  node  (or  subnode)  level.  The  partition  may  be  a property 
of  the  node  and  also  of  one  or  more  facts  In  the  node.  In  that  case  the 
partition  established  for  the  node  applies  to  only  those  facts  which  are 
not  qualified  by  membership  in  another  partition.  In  these  regards,  the 
partition  behaves  in  the  same  way  as  other  properties  of  a fact  or  node.  The 
use  of  partitioning  in  semantic  networks  has  been  described  by  Hendrix  [5]  and 
Its  use  here  In  the  STIS  Concept  Net  is  quite  similar. 


4.7.1 


Physical  (Top-level)  Partitioning 


Partitioning  of  the  Concept  Net  into  physically  independent 
sections  at  the  highest  level  is  provided  to  allow  efficiency  of  local  refer- 
encing within  an  application  area,  and  to  allow  the  systems  manager  to  make 
timely  allocation  of  potentially  scarce  resources  to  such  application  areas. 
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The  partitioning  criterion  (such  as  Area  of  Responsibility)  is 
applied  during  node  processing.  In  simple  cases,  the  partition  reference 
number  can  be  determined  by  reference  to  a table,  such  as  that  shovm  in  Table 
A-l(a).  The  partition  number  is  used  in  all  calls  to  the  Storage  Manager. 

The  Storage  Manager  is  unaware  of  the  criteria  by  which  the  partition  number 
is  determined. 


Physical  partitioning  of  data,  and  associated  loading  and  unload- 
ing of  complete  partitions,  is  supported  at  the  storage  managment  level  through 
a number  of  devices; 

(a)  A partition  may  consist  of  a comp lei  • file,  or  a single 
file  may  be  divided  into  a number  of  partitions. 

(b)  Separate  direct  access  storage  allocation  maps  are 
associated  with  (and  physically  reside  in)  each  par- 
tition. 

(c)  Allocation  requests,  and  I/O  operations,  are  associated 
with  appropriate  physical  file  space  through  the  use  of 
a partition  status  table,  (see  Table  4-1 (b)) 

(d)  The  partition  status  table,  in  addition  to  Infoirmatlon 
about  currently  ’’resident"  physical  partitions,  contains 
Information  about  the  characteristics,  locations,  and 
status  of  "off-line"  partitions. 

(e)  Facilities  are  provided  to  the  STI  system  manager  for 
the  rollin  or  rollout  of  partitions  between  on-line 
mass  storage  files  and  off-line  lower  levels  of  storage. 
Suitable  interlocks  are  provided  during  such  operations. 

(£)  The  STI  system  manager  can  make  inquiries  with  respect 
to  partition  status  information  (including,  potentially, 
usage  statistics)  and  can  update  certain  partition  status 
table  elements. 


Intra-partition  references  are  made  via  a relative  block  number 
(or  its  equivalent).  References  within  a node  to  another  partition  are  accomp- 
lished through  a reference  pair  consisting  of  a partition  number  and  a relative 
block  number  within  that  partition. 
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A. 7. 2 


Consistency  and  Context  Set  Partitions 


Partitions  can  be  used  to  establish  the  set  of  facts  which  be-* 
long  to  a particular  analyst,  or  which  are  valid  or  consistent  with  respect 
to  a given  criterion.  For  example,  suppose  we  have  two  seta  of  facts,  B1  and 
B2  (not  necessarily  disjoint),  which  are  consistent  with  stated  criteria  Cl 
and  C2,  respectively.  In  Figure  A-3,  B1  and  B2  point  to  partitions  S3  and 
SA,  respectively,  and  Indicate  their  membership  in  consistency  sets  Cl  and  C2. 
B1  and  B2  Identify  the  partitions  as  conjunctive  sets,  that  is,  the  following 
are  considered  Independent  sets  of  consistency  statements: 

B1  - { WOba,  WOde,  WAbc,  DAec  } 

B2  - { WObf,  WOde,  DAec,  DAfg  } 


A. 7. 3 


Use  of  Partitions  in  Representing  Rules 


The  Concept  Net  must  have  the  capability  to  represent  not  only 
explicit  sets  of  facts,  but  also  general  rules  which  are  unambiguously  quanti- 
fied variables  in  specific  domains.  For  example,  we  wish  to  be  able  to  state 
that  if  a person  works  on  a system  which  is  developed  at  a particular  plant, 
then  that  person  works  at  chat  plant.  Symbolically,  for  any  x,y,  and  z, 

WOxy  A DAyz  WAxz 

This  can  be  represented  in  the  Concept  Net  several  ways.  One  way  Is  an  impli- 
cation statement  (as  above).  An  equivalent  representation  is  the  Nand  (Not-and) 
form 

(fwOxy  DAyz  WAxz). 

This  latter  representation  is  closely  related  to  the  (disjunctive)  clause  form 
proposed  for  the  inference  mechanism: 

(VffOxy  DAyz  WAxz) 

The  implication  statement  form  of  the  rules  is  shown  as  both  a 
Net  Graph  and  a Node  Diagram  in  Figure  A-A.  The  Nand  form  of  the  *.ule  is  shown 
in  Figure  A-5.  Both  figures  illustrate  the  essential  use  being  made  of  partitions 
to  establish  the  scope  of  sets  of  various  types. 


Consistency  sets  made  up  of  rules  and  facts  are  further  illustra 
ted  in  Figure  A-6. 
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Figure  4-3  Fact  Partitions  Example 
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REPORTS 


The  reports  made  to  the  informatj.on  system  may  be  regarded  as  the 
foundation  for  all  the  Intelligence  Information  of  the  system.  Because  of 
the  need  to  protect  this  initial  fundamental  Informatloni  which  comes  to  the 
system  In  many  ways,  it  la  stored  In  a Report  Net  whose  structure  may  have 
significant  differences  from  the  Entity  Net  in  which  the  analyzed  and  reduced 
Information  of  the  system  is  stored. 

In  addition,  the  particular  procedures  that  the  analyst  or  Data 
Base  Administrator  employs  to  maintain  and  modify  the  Entity  Net  Information 
in  the  light  of  new  reports  are  very  varied.  It  appears  important  to  maintain 
a well  protected  record  of  system  reports  so  that  far-reaching  reorganization 
of  the  Entity  Net  can  be  effectively  accomplished.  Frequent  changes  are  ex- 
pected about  what  Information  is  important,  and  what  system  techniques  are 
practical. 

4.8.1  Report  Net  Structure 

It  Is  expected  that  reports  will  be  stored  in  the  text  in  which  re- 
ceived, as  protection  for  the  accuracy  and  completeness  of  the  report  informa- 
tion and  maintained  in  time  sequence,  as  a historical  log.  In  order  to  provide 
reasonable  search  and  association  capabilities,  the  analyst  will  provide  a de- 
scription list  In  Concept  Node  format,  characterizing  the  report  and  its  salient 
information,  thus  forming  a report  header.  For  example,  a missile  site  firing 
report  may  contain  a bulky  set  of  trajectory  Information,  and  also  identification 
and  summary  Information,  such  as  a range  capability  estimate  completed  from  the 
trajectory  data.  At  the  discretion  of  the  Data  Base  Administrator,  the  above 
discussed  Process-Hook  capability  may  be  employed,  treating  the  original  bulky 
report  as  a fixed  file. 

On  the  other  hand,  the  report  identification  and  qualification  in- 
formation, together  with  certain  computer  values,  may  be  stored  in  time  sequence, 
but  with  a structure  like  that  of  a Concept  Node,  in  order  that  search  and  asso- 
ciation capabilities  be  available.  Depending  upon  search  and  operating  conditions. 
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it  may  be  practical  to  maintain  separate  logs  of  reports  dealing  with  different 
classes  of  information,  with  appropriate  cross  reference  features.  Also,  at 
the  discretion  of  the  Data  Base  Administrator,  references  to  outside  sources 
such  as  documents,  recordings,  witnesses,  or  photographs  may  be  included  with 
the  identification  and  qualification  Information.  Occasionally,  such  infor- 
mation may  be  more  illuminating  than  the  original  report  details. 

4.8.2  Report  Procedures 

The  intelligence  maintenance,  search,  and  interpretation  problems 
are  reflected  in  both  the  structure  used  lOr  the  reports,  and  also  the  pro- 
cedures employed  in  Incorporating  the  report  intelligence  throughout  the 
Concept  Net.  Great  variability  is  anticipated  in  these  procedures,  and  it 
appears  that  valuable  insights  into  the  practicality  of  data  organization 
questions  can  be  obtained  from  considering  such  procedures.  This  appears  to 
apply  to  both  the  Report  Net  structure  and  also  the  Entity  Net  structure. 

First,  there  is  the  considerab’a  variety  of  anticipated  reports. 

There  may  be  a report  whose  impact  on* tuc  intelligence  system  may  be  slight, 
consisting  of  a routine  updating  of  some  estimated  value  appearing  once  or 
twice  in  the  Entity  Net.  Alternatively,  a report  may  appear  which  leads  to 
the  establishment  of  new  Entity  Net  facts,  or  the  reorganizing  of  old  ones. 

It  is  possible  that  the  simple  absence  of  certain  reports  may  carry  more  in- 
telligence than  those  that  actually  arrive  during  a certain  period  of  time. 

Second,  there  is  the  relative  importance  of  maintenance  vs.  re- 
trieval in  the  operation  of  the  system.  One  viewpoint  emphasizes  the  mainte- 
nance a.’d  construction  aspects  of  the  information  system  (updating  the  Entity 
Net  from  new  reports),  since  it  follows  the  natural  flow  of  information  pro- 
cessing and  distillation.  The  other  viewpoint  emphasizes  the  information 
search  and  interpretation  aspect  of  the  system  (retrieval  of  Entity  Net  facts) 
which  may  comprise  the  bulk  of  the  system  activity.  However,  a balance  must 
be  sought  since  this  activity  is  dependent  upon  an  effective  information  main- 
tenance and  constructiwvn  procedure  in  utilizing  the  fundamental  information  which 
flow  from  the  reports. 
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REPORTS 


The  reports  made  to  the  Information  system  may  be  regarded  as  the 
foundation  for  all  the  Intelligence  Information  of  the  system.  Because  of 
the  need  to  protect  this  Initial  fundamental  Information,  which  comes  to  the 
system  In  many  ways,  It  la  stored  In  a Report  Net  whose  structure  may  have 
significant  differences  from  the  Entity  Net  In  which  the  analyzed  and  reduced 
Information  of  the  system  Is  stored. 

In  addition,  tha  particular  procedures  that  the  analyst  or  Data 
Base  Administrator  employ?  to  tialntaln  and  modify  the  Entity  Net  Information 
In  the  light  of  new  reports  are  very  varied.  It  appears  Important  to  maintain 
a well  protected  record  of  system  reports  so  that  far-reaching  reorganization 
of  the  Entity  Net  can  be  effectively  accomplished.  Frequent  changes  are  ex- 
pected about  what  Information  Is  Important,  and  what  system  techniques  are 
practical. 


4.8.1  Report  Net  Structure 

It  Is  expected  that  reports  will  be  stored  In  the  text  In  which  re- 
ceived, as  protection  for  the  accuracy  and  completeness  of  the  report  Informa- 
tion and  maintained  In  time  sequence,  as  a historical  log.  In  order  to  provide 
reasonable  search  and  association  capabilities,  the  analyst  will  provide  a de- 
scription list  in  Concept  Node  format,  characterizing  the  report  and  its  salient  i 

information,  thus  forming  a report  header.  For  example,  a missile  site  firing  i 

report  may  contain  a bulky  set  of  trajectory  information,  and  also  identification 
and  summary  information,  such  as  a range  capability  estimate  completed  from  the 
trajectory  data.  At  the  discretion  of  the  Data  Base  Administrator,  the  above 
discussed  Process-Hook  capability  may  be  employed,  treating  the  original  bulky 
report  as  a fixed  file. 

On  the  other  hand,  the  report  identification  and  qualification  in- 
formation, tog  cher  with  certain  computer  values,  may  be  stored  in  time  sequence, 
but  with  a structure  like  that  of  a Concept  Node,  in  order  that  search  and  asso- 
ciation capabilities  be  available.  Depending  upon  search  and  operating  conditions,  j 
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4 . 8 . 2 . 1 Simple  Updating  of  Entity  Net  Facts 

Suppose  that  a report  Is  received  that  a particular  radar  system  Is 
developed  at  a particular  plant.  This  may  support  a fact  already  In  the  Entity 
Net,  In  which  the  radar  system  might  appear  as  system  //31,  and  the  plant  as 
facility  //47.  Thus,  there  Is  no  change  anticipated  anywhere  In  the  Entity  Net, 
except  for  a revision  upward  of  the  truth  probability  for  a fact  already  listed 
In  the  Entity  Net.  If  the  appropriate  system  authority  places  a high  estimate 
on  the  reliability  (or  likelihood)  of  the  report,  then  the  fact  credibility 
(truth  probability)  takes  a correspondingly  large  upward  revision. 

A further  Illustration  would  be  a tracking  radar  report  of  a routine 
missile  firing  from  a particular  site.  It  is  likely  that  this  may  affect  sev- 
eral facts  In  the  Entity  Net,  but  each  as  a simple  update.  It  may  be  that  facts 
are  being  maintained  as  follows: 

(1)  Best  current  range  capability  estimate 

(2)  Best  current  staging  time  estimate 

(3)  Count  of  weekly  firings  or  mlsfirlngs 

The  two  estimates  are  likely  to  be  improved  by  the  computed  values  from  the 
incoming  report,  possibly  using  statistical  tools  rather  than  the  truth  prob- 
ability method  of  the  earlier  example.  The  firing  count  may  be  set  up  without 
any  credibility  Implementation. 

The  above  has  been  deed  as  a routine  firing  report.  If,  however, 
there  is  a problem  about  whether  the  supposed  site  has  been  incorrectly  Identi- 
fied, or  the  precise  identity  of  the  missile  type,  then  the  reports  are  no 
longer  routine.  The  problems  In  Identification  and  interpretation  may  lend  to 
initiating  new  (or  retiring  old)  facts  from  the  Entity  Net. 

4. 8. 2. 2 Initiating  New  Facts  in  the  Entity  Net 

If  we  suppose,  then,  that  missile  trajectory  reports  are  being  re- 
ceived from  a tracking  radar  under  conditions  where  an  attempt  Is  being  made 


to  identify  the  missile  type  (or  types),  a large  number  of  facts  may  be  initiated 
and  maintained  in  the  Entity  Net.  For  example,  summary  calculated  values  may  be 
maintained  for  each  reported  trajectory.  This  contrasts  strikingly  with  the 
routine  situation  in  which  we  supposed  only  the  maintenance  of  current  estimat- 
ed averages  or  firing  counts  for  the  missile  site.  Vfhen  the  missile  type  identi- 
fication is  complete,  then  the  facts  of  the  Concept  Net  may  be  reorganized  in 
the  simpler  and  more  compact  manner  fitting  the  routine  situation.  If  we  suppose 
that  unexpected  information  arrives,  indicating  the  need  to  restudy  the  identi- 
fication problem  under  modified  assumptions,  recourse  may  be  had  to  the  original 
reports  to  appropriately  reassess  the  picture. 

Parallel  situations  appear  likely  in  otaer  information  areas.  It 
may  be  that  a large  number  of  carefully  organized  facts  may  be  maintained  on 
a permanent  basis  in  the  Entity  Net,  related  to  a scientist  of  a critical  im- 
portance. On  the  other  hand,  a large  number  of  facts  may  be  maintained  on  a 
temporary  basis  related  to  another  scientist  for  whom  there  is  an  Identification 
issue. 


4.8. 2.3  Alertness  to  the  Absence  of  Reports 

It  seems  reasonable  to  anticipate  that  absence  of  reports  may 
frequently  be  of  crucial  significance,  and  yet  the  initiation  of  the  appro- 
priate alert  status  or  action  may  not  be  in  the  area  of  report  procedures  or 
organization.  Two  illustrations  are  considered. 

First,  we  suppose  that  firing  reports  for  a missile  site  cease  (or 
drop  off  sharply)  during  a time  interval.  This  is  likely  to  become  apparent 
when  a Entity  Net  fact,  such  as  the  count  of  weekly  firings,  is  inspected  or 
reviewed.  Interpretation  and  action  may  likely  result  from  a search  and 
study  of  related  facts.  Perhaps  the  nearby  missile  sites,  or  supply  activities 
may  furnish  illuminating  information. 

Second,  we  suppose  that  the  quantity  of  firing  reports  does  not  alter, 
but  rather  the  quality.  If  the  reports  indicate  a steadily  increasing  site 
range  capability,  this  is  likely  to  become  apparent  from  observation  of  Entity 
Net  facts  concerning  present  and  old  range  capability  estimates.  Neither  the 
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absence  of  reports,  nor  a trend  In  the  Information  content,  is  apt  to  be  appar- 
ent at  the  report  level. 

It  appears,  then,  that  the  quality  and  quantity  of  Incoming  reports 
will  often  be  recognized  and  coped  with  as  part  of  the  information  search,  re- 
view and  interpretation  procedures  associated  mainly  with  the  use  of  the  Entity 
Net.  It  is  Important  that  report  information  is  adequately  distilled  into  the 
Entity  Net,  of  course.  Even  lack  of  report  Information  should  be  so  distilled. 
The  decay  of  fact  credibility  discussed  in  Section  4.1  is  one  example.  The 
firing  count  may  serve  to  indicate  lack  of  reports,  as  mentioned  above. 

4. 8. 2. 4 Composite  Reports 

Especla"' ly  when  the  source  is  non-instrumental,  a report  can  appear 
that  may  well  be  treated  as  several  reports,  even  if  tho  facts  are  interwoven 
in  lengthy  sentences.  Entity  Net  facts  may  then  be  initiated,  modified,  or 
updated  in  much  the  same  way  as  if  the  report  were  a series  of  simple  reports. 
It  may  well  be  that  the  report  will  be  logged  in  and  recorded  as  a single  com- 
posite report  in  order  to  maintain  the  original  text  for  purposes  of  informa- 
tion security.  The  Report  Node,  mentioned  in  Section  4.6.1  above,  is  apt  to 
be  bulky  because  of  the  heavy  requirements  to  provide  search  and  association 
capabilities  where  the  information  is  composite. 

4. 8. 2. 5 Multiple  Versions  and  Appearances  of  the  Same  Fact 


It  is  likely  that  differing  agencies  and  differing  Instrumentation 
will  lead  to  separate  estimates  for  the  same  technical  quantity,  whether  it 
is  the  percentage  of  a metal  in  a compound,  an  estimated  range  capability,  or 
something  very  diverse.  For  easons  of  information  responsibility,  clarity, 
and  security,  such  separate  estimates  will  be  maintained  almost  as  if  they 
were  separate  facts. 

It  is  a some  what  different  matter  when  differing  records  are  kept 
of  an  identical  fact  for  search  efficiency  reasons.  One  illustration  la  the 
fact  that  person  #32  works  at  facility  #12,  routinely  stored  in  "attributes- 
under-entlty"  format  in  the  Entity  Net  part  of  the  Concept  Net  relating  to 
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person  //32.  The  same  fact  may  be  stored  also  as  part  of  an  employment  list 
In  a "works  at"  Attribute  Node  in  the  Semantic  Net  (also  in  the  Concept  Net). 

This  permits  the  retrieval  of  general  employment  information  at  one  facility 
witho..t  laborious  general  searching  through  the  Entity  Net  entries  for  vari- 
ous persons. 

A.8.2.6  Multiple  Results  From  One  Report 

Sometimes  we  expect  one  report  to  contribute  to  one  Concept  Net  fact 
already  initiated  with  other  reports,  with  possible  complications  in  the  ver- 
sions and  storage  of  that  fact.  It  is  also  possible  that  distinct  Concept  Net 
facts  may  be  involved. 

For  example,  a missile  firing  may  call  for  firing  count,  range  capa- 
bility, staging  time  and  other  updating  of  estimates,  as  already  indicated  in 
discussing  simple  updating.  It  may  be  that  both  specific  estimates  for  the 
particular  missile  site,  and  general  estimates  for  the  missile  type  design  are 
involved  and  must  be  separately  updated.  Such  practice  may  stem  from  interest 
in  the  geographic,  supply,  and  operational  effects  in  various  site  locations. 

4.8.3  System  Report  Procedures  and  Report  Net  Structure 

It  appears  that  there  is  considerable  interplay  between  the  proce- 
dures and  the  data  structure  employed  as  the  report  information  is  entered 
into  the  STIS.  In  particular  the  Report  Net  occupies  a special  fundamental 
positiion  from  which  restructuring  of  the  Entity  Net  is  occasionally  likely, 
making  information  security  specially  important  In  the  Report  Net. 

If  the  set  of  Entity  Net  facts  in  some  information  area  is  to  be 
abbreviated,  it  is  possible  that  the  restructuring  may  be  accomplished  with- 
out recourse  to  the  Report  Net.  A simple  illustration  would  be  to  change 
the  firing  time  interval  for  a missile  count  record  from  a monthly  to  a quarterly 
span.  If  the  reorganization  of  Entity  Net  facts  is  more  far-reaching,  or  more 
detailed,  then  the  Report  Net  is  needed. 

We  note  that  the  Data  Base  Administrator's  task  in  entering  reports 
is  subtle  and  substantial,  even  when  the  operation  is  on  a routine  basis. 
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This  Is  in  part  because  the  search  and  investigation  needs  of  a whole  commu- 
nity of  analysts  are  to  be  met.  It  would  be  especially  onerous  if  many  analysts 
felt  a frequent  need  to  go  to  the  reports  because  of  dissatisfaction  with  the 
distilling  process  done  in  Entity  Net  facts.  Occasional  temporary  alternations 
in  Entity  Net  Information,  without  recourse  to  the  reports  themselves,  is  apt 
to  be  more  tolerable,  partly  because  of  the  difference  in  data  bulk.  These 
considerations  take  on  added  weight  when  the  Information  situation  necessitates 
serious  Entity  Net  reorganization. 


SECTION  V . PERIPHERAL  FILE  ACCESS  SUBSYSTEM 


5 . 1 BACKGROUND 


The  current  production  and  test  versions  of  STIS  utilize  a number 
of  physical  files,  which  taken  together  comprise  the  data  base,  to  store  and 
manipulate  information  entered  by  the  intelligence  analyst  or  application  pro- 
gram. The  primary  file  consists  of  the  network  structure  of  nodes  represent- 
ing sets,  generic  and  specific  entities,  states,  etc.  The  access  method  to 
read,  store,  and  traverse  this  network  is  a direct  one  based  on  a computable 
relative  mass  storage  address  from  a node  identification  number.  This  ID 
number  is  sequential  and  each  node  is  assigned  the  next  number  by  STIS  upon 
itf  he  node"s)  creation.  Each  node  is  assigned  a predetermined  contiguous 
s of  mass  storage  space  for  which  the  first  sector  is  directly  address- 

abi..  v.a  its  ID  number.  Overflow  of  this  initially  allocated  segment  is 
handled  by  linking  to  subsequent  chained  segments  in  an  overflow  file. 

The  remaining  files  are  used  in  conjunction  with  the  node  network 
to  respond  to  inputs  from  the  analyst.  When  sets  are  defined  in  their  English 
language  terms,  STIS  assigns  an  ID  number,  eferenced  above,  to  them.  But 
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the  correlation  between  term  and  ID  number  is  stored  In  the  Set  Term  file 
where  the  term  becomes  a key  for  the  ID  number.  The  same  procedure  holds 
true  for  states  of  entities  and  for  attribute  definitions.  Additional  files 
contain  fact  control  information,  log-on/ log-off  entries,  and  an  external 
invoked  process  log.  The  access  method  used  to  manage  these  secondary  files 
is  the  Univac  supplied  ISFMS  package. 

ISFMS  is  a hierarchial  index  sequential  access  method  using  chained 
overflow  data  block  pointers.  It  is  a single  thread  (user)  package.  Hence, 
it  provides  no  protective  physical  or  logical  record  lock  mechanism  in  the 
event  two  or  more  concurrent  users  are  attempting  to  update  the  same  data 
files.  ISFMS,  being  non-reentrant,  necessitates  each  concurrent  user  suffer- 
ing the  overhead  of  having  his  own  core  copy  of  it  along  with  the  buffers  needed 
to  support  each  file.  Physical  blocks  may  only  be  selected  at  the  1/A,  1/2, 
or  full  track  level  (AA8,  896,  or  1792  words  respectively).  The  index  blocks 
for  any  given  file  may  not  be  permanently  saved  and  accessed  in  a separate 
physical  file,  although  run  temporary  index  files  may  be  created,  used,  then 
discarded.  File  reorganization  can  take  place  more  often  than  desired  due 
to  the  chained  overflow  mechanism  if  there  is  heavy  create/delete  activity  in 
the  file.  The  chaining  mechanism, can  also  require  additional  I/O  accesses 
and  block  search  time  when  locating  a unique  key. 

5.2  REQUIREMENTS 


Based  on  the  current  and  projeci«d  requirements  of  the  STI  system, 
the  peripheral  file  access  subsystem  was  designed  to  meet  the  following  cri- 
teria: 


1)  be  reentrant  thus  supporting  a multi-user  environment 
and  reducing  user  core  requirements 

2)  provide  proper  protective  access  to  common  files  and 
records 

3)  perform  functions  with  minimum  response  time 

A)  efficiently  manage  STIS  terra  type  data 

5)  handle  a large  number  of  data  records  (approximately 
200,000  to  500, 0?0  terms)  with  high  'creace/delete' 
activity 
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ACCESS  SUBSYSTEM  DESCRIPTION 


5.3.1  Approach  and  Design  Considerations 

The  access  method  developed  retains  the  Indexed  sequential  approach 
of  ISFMS.  An  analysis  of  term  lengths  shows  that  any  term  may  extend  to  180 
characters  with  30  characters  the  average  length.  This  variation  In  term 
size  as  well  as  the  expected  size  of  the  term  list  (200,000  to  500,000)  pre- 
cludes any  effective  type  of  computed  address  or  direct  address  approach. 

The  design  of  the  subsystem,  considered  in  view  of  the  STTS  requirements  as 

I 

enumerated  above,  follows. 

5 . 3 . 1 . 1 Reentrancy  and  User  Core  Size  Reduction 

Under  the  earlier  versions  of  the  Unlvac  EXEC  8 operating  system 
and  prior  to  the  introduction  of  the  1110  hardware,  a reentrant  program  was 
a self-contained  'I  Bank  only'  program.  Each  user  program  wishing  to  exe- 
cute the  reentrant  program  would  'link  to'  it  by  executing  an  Executive  Re- 
quest from  his  own  program.  The  reentrant  program  consists  solely  of  instruc- 
tion code,  and  data  and  sufficient  working  storage  for  its  own  housekeeping. 
User  dependent  working  stroage  must  be  allocated  in  the  user  program  and  would 
include  any  I/O  buffers  needed  for  mass  storage  files.  Thus,  creating  a re- 
entrant version  of  the  access  subsystem  (much  on  the  same  design  lines  as 
FMS-8)  would  not  be  sufficient  to  save  STIS  the  memory  overhead  normally 
allocated  for  I/O  buffers.  This  could  amount  to  5500  words  per  user  based 
on  six  peripheral  files,  double  buffering,  and  minimum  1/4  track  blocks. 

The  upgrading  at  FTD  from  the  Unlvac  1108  to  1110  provided  a new 
joint  hardware/software  technique  that  would  allow  concurrent  users  to  exe- 
cute common  instructions  and  share  common  data  areas . The  access  subsystem 
was  designed  to  be  written  as  a set  of  reentrant  modules  and  collected  to- 
gether as  a common  instruction  bank  sharable  by  as  many  concurrent  users  who 
'link  to'  it  via  a hardware  'load  instruction  bank  and  Jump'  (LIJ)  instruction. 
A single  set  of  I/O  buffers  will  reside  in  a common  data  bank  and  these  will 
be  used  to  service  all  the  concurrent  users.  Each  user's  core  requirements 
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then  have  been  reduced  to  providing  only  a small  area  for  control  tables 
and  working  storage.  The  EXEC  8 operating  system  will  always  maintain  the 
latest  copies  of  the  common  I and  U banks  both  In  core  and  on  the  system  mass 
storage  swap  area.  This  assures  that  any  changes  made  to  tables,  buffers,  etc. 
by  the  access  subsystem  will  be  preserved. 

5 . 3 . 1 . 2 Common  File  and  Record  Access 


Once  a user  has  linked  to  the  access  subsystem,  his  command  and 
argument  list  will  be  checked  for  validity.  Access  to  a file  after  validity 
checks  are  passed  will  be  controlled  by  a hardware  'test  and  set'  Instruction 
on  a specially  marked  cell.  This  will  effectively  lock  out  all  other  concurrent 
users  from  using  that  file.  If  the  file  Is  currently  being  accessed  by  another 
user,  then  the  EXEC  8 operating  system  will  place  the  new  user  on  a queue  main- 
tained by  it.  When  the  previous  user's  file  request  has  been  completed,  the 
file  la  unlocked  by  the  access  subsystem  and  the  operating  system  will  activate 
the  next  user  on  the  queue  for  this  file  (if  any).  Each  file  opened  and  being 
manipulated  by  the  access  subsystem  will  have  Its  own  specially  marked  lock 
word  and  queue  maintained  by  EXEC  8.  Each  file  has  Its  own  dedicated  buffer 
area  within  a common  data  area  pool.  Thus,  the  access  package  may  perform  a 
single  request  concurrently  on  each  file  opened  within  it  with  multiple  re- 
quests on  any  given  file(s)  automatically  queued  by  EXEC  8. 

Certain  users  may  be  declared  by  STIS  to  be  inelllglble  for  writing 
information  into  the  data  base.  This  inelllgibility  might  be  determined  from 
the  user's  password.  STIS  then  might  specify  to  the  access  subsystem  that 
certain  files  may  be  addressed  in  the  'read  only'  mode  for  those  users.  The 
access  subsystem  has  been  designed  to  protect  against  write  operations  on 
'read  only'  files. 

In  addition  to  Its  own  Internal  common  file  access  mechanism,  the 
subsystem  allows  individual  users  to  place  a logical  lock  on  any  selected 
record  in  a file.  This  logical  lock  inhibits  all  requests  (except  for  'inquiry 
only'  requests)  for  this  record  by  other  users  until  the  lock  is  cleared  by 
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the  orglnaClng  user.  An  analysis  of  typical  operations  on  the  peripheral 
files  shows  that  only  one  record  lock  per  user  per  file  should  occur.  Based 
on  this,  the  access  subsystem  will  permit  each  user  to  set  one  lock  on  each 
file  he  has  open.  A provision  to  expand  the  number  of  locks  per  file  Is 
available  by  redefining  a parameter  and  reassembly. 

5. 3. 1.3  Minimize  Response  Time 

The  access  subsystem  permits  the  index  blocks  for  any  file  to  be 
optionally  maintained  in  a separate  catalogued  index  file  (as  opposed  to  being 
embedded  within  the  same  file  containing  the  actual  data  blocks).  Separate 
index  block  files  permit  overlap  of  some  I/O  activity  through  channel  separa~ 
tlon  on  differing  mass  storage  devices  or  on  dual  access  devices  (e.g.,  FTD's 
8440  disc  subsystem). 

Separate  buffers  are  allocated  and  dedicated  to  the  highest  level 
index  block  for  each  file  opened  within  the  subsystem.  An  additional  buffer 
is  utilized  for  lower  level  Index  blocks.  All  unnecessary  'reads'  are  avoided 
if  the  appropriate  Index  and  data  blocks  for  a given  file  are  already  buffer 
resident. 

5. 3. 1.4  Manage  STIS  Term  Data 

The  access  subsystem  will  support  a file  which  has  records  In  which 
the  key  and  data  portion  may  be  variable  or  fixed  in  length.  The  file  organi- 
zation Is  specified  by  the  STIS  programmer.  Once  specified,  all  records  with- 
in that  file  must  conform  to  the  type  given.  Generally,  there  will  be  a one- 
to-one  correspondence  between  key  and  data  entry  of  a record.  However,  an 
analysis  of  the  present  STIF  term  files  (set,  plane,  and  attribute  term  files) 
showed  that  one  English  term  could  represent  more  than  a single  role  (e.g.,  be 
both  a set  and  attribute).  Thus,  there  are  duplicate  term  entries  In  tVie 
current  files.  Combining  these  files  Into  a single  term  file  would  not  only 
reduce  duplicate  storage  but  also  reduce  search  time  for  language  processing 
functions  requiring  all  uses  of  a given  term.  The  access  subsystem  was  de- 
signed to  allow  for  a one-to-many  correspondence  between  key  and  data  entries 
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of  a record.  Each  data  entry  la  tagged  by  a role  code  Indicator  (which  may 
be  interpreted  as  a secondary  key  suffixed  to  the  primary  key).  Thus,  a 
file  of  terms  might  be  created  where  a key  is  the  English  term  and  the  data 
entries  are  the  specific  nodes  In  the  network  file  which  represent  the  differ- 
ing uses  of  the  term. 

5. 3. 1.5  Large  Record  Volume  with  High  Create/Delete  Activity 

File  reorganisation  was  one  of  the  prime  considerations  In  the  de- 
sign of  the  access  subsystem.  It  was  felt  that  as  much  maintenance  should 
be  performed  as  was  possible  during  the  execution  of  requests  which  physically 
alter  the  data  content  of  a given  file.  This  was  especially  true  of  a dy- 
namically expanding  and  contracting  file  such  as  a common  STIS  term  file.  The 
maintenance  function  must  be  considered  when  performing  a DELETE,  MODIFY,  or 
INSERT  operation.  A DELETE  request  causes  the  key  and  data  entries  to  be  re- 
moved from  the  data  block  In  which  they  reside.  The  data  block  is  compacted; 
the  block  control  words  updated;  and  the  data  block  Is  rewritten  to  mass  stor- 
age. The  deleted  space  Is  then  Immediately  available  for  reuse.  An  INSERT 
request  causes  a key  and  data  entry  to  be  added  to  a data  block.  If  the  phy- 
sical data  block  will  overflow  due  to  the  size  of  the  new  entry,  a data  block 
split  Is  performed.  An  attempt  Is  made  to  split  the  old  block  equally  with 
a new  data  block  and  the  Insertion  made  In  the  appropriate  place.  However,  in 
some  cases,  a second  additional  block  may  be  necessary  to  properly  split  and 
sequentially  maintain  the  data  records.  After  the  insertion  is  made  at  the 
data  block  level,  the  Index  blocks  need  to  be  updated  since  an  additional  1 
or  2 data  blocks  were  created.  The  same  procedure  outlined  above  Is  used  to 
update  the  Index  blocks.  As  a lower  level  Index  block  overflows,  its  next 
higher  level  block  Is  updated  until  the  current  highest  level  Is  reached. 

If  the  current  highest  level  block  overflows,  a new  Index  level  Is  generated. 
The  access  subsystem  Is  designed  to  handle  an  unlimited  number  of  Index  levels. 
(Figure  5-2  depicts  In  a simplified  style  the  results  of  an  INSERT  operation.) 
A MODIFY  request  on  a variable  length  data  entry  file  may  cause  contraction 
or  expansion  of  a data  block  depending  on  the  new  data  entry  size.  If  con- 
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traction  is  indicated,  the  DELETE  procedure  is  basically  used;  if  expansion, 
the  INSERT  procedure  is  basically  used. 

5.3. 1.6  Key  and  Data  Considerations 

Since  the  access  package  does  not  employ  a chained  overflow  block 
technique,  no  record  then  may  extend  across  block  boundaries  (i.e,  no  record 
consisting  of  key  entry  and  data  entry  or  multiple  data  entries  when  qualified 
by  role  code  may  exceed  the  sice  of  a physical  data  block). 

In  a hlerarchial  index  sequential  file,  there  must  exist  some 
single  high  level  index  pointer  block.  The  length  of  the  key  entries  with- 
in this  block  must  be  less  than  or  equal  to  one  half  the  effective  block  size. 
If  this  were  not  so,  there  would  exist  the  possibility  that  only  1 key  entry 
could  reside  in  an  index  block.  Each  index  block  must  be  able  to  hold  at 
least  two  keys  (known  as  'range*  keys)  in  order  to  generate  a hlerarchial 
structure.  An  index  'range'  key  is  used  to  point  to  a lower  level  index  or 
data  block  in  which  the  'range'  key  Itself  is  the  lowest  order  sequential  key. 


In  Figure  5-1,  Range  Key  Indices 


the  'range'  key  in  level  2 points  to  a block  at  level  1 in  which  K^  is  the 
lowest  ordered  key.  The  same  holds  for  'range'  key  K^^,  on  level  2.  Thus,  all 
the  records  that  have  a key  between  'range'  key  K^  and  up  to  but  not  induing 
'rrnge'  key  K.„  are  contained  in  the  level  1 block  pointed  to  by  ’^AA* 


The  very  first  record  that  must  be  loaded  into  a file  should  have 
a key  consisting  of  binary  zeroes.  This  key  will  function  as  an  initialization 
sentinel.  It  will  appear  a.^  the  firut  range  key  in  each  successively  higher 
index  level  block.  Its  appearance  guarantees  that  no  sequentially  lower  (in 
the  alpha  numeric  collating  sequence.)  key  can  be  constructed  and  possibly 
cause  problems  on  retrieval  operations. 


The  access  subsystem  has  been  designed  such  that  an  index  block 
overflow  caused  by  an  insertion  of  a new  'range'  key  must  be  restructured  with 
the  addition  of  only  one  new  index  block.  The  old  and  new  'range'  keys  will 
be  divided  as  equally  as  possible  within  the  old  and  new  Index  blocks.  This 
design  constrains  the  maximum  key  entry  size  to  30%  of  the  physical  index  block 
size.  For  the  smallest  size  Index  block  assignable  by  the  programmer  of  112 
words  (Unlvac  8A40  standard  disc  prep  size),  the  largest  size  key  cannot  ex- 
ceed approximately  33  words  or  198  characters.  This  appeared  very  unlikely 
to  occur  within  STIS.  Figure  5-2  shows  the  reformatted  index  and  data  blocks 
after  an  oi^erflow  caused  by  an  INSERT  operation. 


5. 3. 1.7  File  Considerations 

The  tables  that  have  been  identified  'or  definition  and  manipulation 
by  the  access  subsystem  are  the  'term  encoding  table',  'word  encoding  table' 

(both  used  by  the  Directory  Services  subsystem),  'fact  control  table',  'log- 
on/off table',  and  'invoked  processor  table'.  An  analysis  of  the  Information 
content  and  current  and  future  usage  statistics  of  these  tables  was  performed. 

The  results  show  that  the  'term  encoding  table'  (or  TET)  and  'word  encoding 
table'  (or  WET)  will  be  the  most  heavily  accessed  tables  and  the  'fact  control 
table'  (or  FCT)  also  frequently  accessed.  Thus,  these  three  tables  should 

have  separate  index  block  files.  The  'log-on/off  table'  and  'invoked  pro-  | 

cessor  table ' are  very  low  access  tables  and  need  not  have  separate  index 
block  files. 


INDEX  LEVEL  2 


We  have  assigned  each  table  a set  of  table  definition  parameters 
based  on  Its  record  structure  and  computed  sample  loading  conditions.  The 
access  subsystem  attempts  to  initially  load  data  blocks  to  50%  of  capacity 
and  to  completely  fill  the  associated  Index  blocks.  The  initial  load  factor 
percentage  may  be  changed  by  reassembly. 

The  following  formulas  are  used  in  computing  the  loading  conditions. 

//  of  Block  Control  Words  (NBCW)  ■ 

Load  Factor  (LF)  ■ 

Data  Record  Size  (DRS)  * 

Key  Size  (KS) 

Max  Keys  (MK)  =• 

Initial  Data  Records  (IDR)  ■ 

Total  Initial  Data  Records  ■ 

(Fractional  sizes  are  rounded 

1)  Term  Encoding  Table  (TET) 

Organization  Is  contiguous  fixed 
Record  Control  Word  = 0 
Key  Length  = 2 words 
Data  Length  = 1 word 
Index  Block  Size  = 336  words 
Data  Block  Size  = 22A  words 
Number  of  Index  Levels  = 2 

DRS-2+0+1-3 
KS  » 2 + 1 = 3 
MK  = (336-3)/3  - 111 
IDR  = ((224-3)/3)  * .50  - 36 

2 

Total  Initial  Data  Records  “ 36  * (111)  “ 443,556 


3 

50% 

Key  Length  + Record  Control 
Word  + Data  Length 

Key  Length  + 1 
(Index  Block  Size  - NBCW)/KS 
((Data  Block  Size  - NBCW) /DRS)  *LF 
IDR  * (MK)^^"’^®’^  Index  Levels 

up  to  next  whole  word) 


key/ fixed  data. 
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Word  Encoding  Table  (WET) 

Organization  is  contiguous  fixed  key/fixed  data 

Record  Control  Word  ■ 0 

Key  Length  *2  words 

Data  Length  ■ 1 word 

Index  Block  Size  - 224  words 

Data  Block  Size  * 336  words 

Number  of  Index  Levels  ■ 2 

DRS-2+0+1-3 

KS  - 2 + 1 - 3 

MS  - (224-3)/3  - 73 

IDR  - ( (336-3) /3)  * .50  - 55 

Total  Initial  Data  Records  ■ 55  * (73)^  ■ 292,545 
Fact  Control  Table  (FCT) 

Organization  is  contiguous  fixed  key/flxed  data 

Record  Control  Word  ■ 0 

Key  Length  » 5 words 

Data  Length  » 2 words 

Index  Block  Size  * 336  words 

Data  Block  Size  - 336  words 

DRS=5+0+2»7 

KS  = 5 + 1 = 6 

MK  = (336-3)/6  = 55 

IDR  = ((336-3)/7)  * . 50  = 23 

Number  of  Index  Levels  =2 

Total  of  Initial  Data  Records  = 23  * (55)  = 69,575 

Number  of  Index  Levels  =3 

Total  Initial  Data  Records  » 23  * (55)'’  = 3,826,625 
Log-On/Off  Table 

Organization  is  contiguous  fixed  key/flxed  data 
Record  Control  Word  = 0 


Key  Length  « 5 words 

Data  Length  = 10  words 

Index  Block  Size  > 112  words 

Data  Block  Size  ■ 112  words 

DRS  - 5 + 0 + 10  - 15 

KS  - 5 + 1 - 6 

MK  - (112-3) /6  - 18 

IDR  - ((112-3)/15)  * .50  - 4 

Number  of  Index  Levels  = 1 

Total  Initial  Data  Records  = 4 * 18  » 72 

Number  of  Index  Levels  =2  2 

Total  Initial  Data  Records  = 4 * (18)  =»  1,296 

5)  Invoked  Processor  Table 

Organization  Is  contiguous  fixed  key/flxed  data 

Record  Control  Word  ■ 0 

Key  Length  =■  5 words 

Data  Length  * 5 words 

Index  Block  Size  = 112  words 

Data  Block  Size  = 112  words 

DRS  = 5 + 0 + 5 = 10 

KS  - 5 + 1 = 6 

MK  » (112-3) /6  « 18 

IDR  = ((112-3)/10)  * .50  = 5 

Number  of  Index  Levels  = 1 

Total  Initial  Data  Records  = 5 * 18  = 90 

Number  of  Index  Levels  =2  „ 

Total  Initial  Data  Records  = 5 * (18')  = 1620 


5.3.2  Functional  Outline 


The  following  basic  user  (i.e.,  STIS  systems  programmer  or  poten- 
tially other  applications  programmers)  functions  are  supported  by  the  access 
subsystem.  The  detailed  description  and  parameter  list  expansion  of  each  is 
given  in  Appendix  B. 
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OPENAP 

DEFNFILE  parm  Hat 
OPEN  parm  list 


Initializes  the  access  subsystem 
for  the  user 

Defines  a new  flic 

Opens  a file  and  Its  associated 
index  file 


H 


READ  RANDOM  parm  Hat 

READ  SEQUENTIAL  parm  list 

READ  RANDOM  w/lock 
READ  SEQUENTIAL  w/lock 

INSERT  parm  list 

MODIFY  parm  list 

DELETE  parm  list 

INFORM  parm  list 

CLOSE  parm  list 

CLOSEAP 

5,3,3  Error  Processing 


Reads  a data  entry  associated  with 
the  given  key 

Reads  a data  entry  associated  with 
next  sequential  key 

As  above  but  also  inhibits  further 
access  to  the  data  record  by  other 
users 

Adds  the  data  entry  associated  with 
the  given  key 

Updates  the  data  entry  associated 
with  the  given  key 

Deletes  the  data  entry  for  the  given 
key 

Gives  the  user  statistics  about 
file  usage 

Performs  an  orderly  closing  action 
on  a file 

Closes  the  access  subsystem  to  the 
user 


The  access  subsystem  performs  a number  of  validity  checks  on  the 
commands  issued  to  it  by  STIS  service  modules.  If  an  error  is  detected,  an 


error  code  is  returned  to  the  calling  module  and  the  command  is  effectively 
not  performed.  It  is  the  calling  module's  responsibility  to  take  the  appro- 
priate action  (e.g.,  Inform  the  user  of  the  error,  reformat  the  command,  etc.) 
after  an  error  code  is  returned.  A complete  list  of  error  codes  and  their 
interpretations  Is  given  in  Appendix  B. 
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SECTION  VI.  DIRECTORY  SERVICES  SUBSYSTEM 
6.1  INTRODUCTION 

The  STI  Directory  Subsystem  consists  of  the  tables  and  program  modules 
shown  in  Figure  6-1.  The  Directory  is  designed  to  uniquely  encode  and  decode 
all  system  words  and  terms  (of  one  or  more  words)  used  in  STIS  as  attributes, 
values,  commands,  and  noise.  These  system  words,  and  terms  are  maintained 
in  integrated  ordered  lists  (the  Word  and  Term  Encoding  Tables)  so  that  an 
input  language  scanner,  using  the  directory  services,  can  recognize  and  deter- 
mine the  role  played  by  every  word  apt  to  be  entered  (including  the  attribute(s) 
associated  with  a value  term),  the  uniqueness  of  a term,  and  the  equivalence 
of  a term  to  other  terms.  The  Directory  functions  and  tables  are  defined  in 
Appendix  C along  with  accompanying  system  level  flow  charts. 

An  analysis  of  the  terms  used  by  analysts  to  define  entity  names, 
attributes,  and  sets  in  STIS  showed  that  terms  often  were  not  unique  in  their 
usage  and  were  often  multi-word.  Words  often  appeared  as  components  of  several 
terms.  The  number  of  characters  in  a word  could  be  as  large  as  twehty  or  as 
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small  as  one  while  the  total  number  of  characters  in  a multi-word  term  could  1 

approximate  180.  Based  on  these  factst  we  attempted  to  define  encoding/decoding 
algorithms  and  data  tables  to  handle  terms  as  a variable  number  of  variable  f 

length  words  and  their  associated  roles.  We  also  investigated  the  possible 
partitioning  of  words  into  meaningful  linguistic  units  or  morphemes  and  the  i 

treating  of  definable  groups  of  words  as  term  fragments. 

4 

6.2  ENCODING  MECHANISM  ' 

All  words  and  terms  are  stored  with  numeric  codes  in  ordered  lists  i 

(via  the  Word  and  Term  Encoding  Tables)  along  with  an  associated  role  map  which 
defines  how  the  word  or  term  is  being  used.  Words  may  be  of  arbitrary  character 
length  and  terms  may  consist  of  any  number  of  words.  In  the  event  a word  is 
too  large  to  be  stored  in  a single  WET  (Word  Encoding  Table)  entry,  it  is 
partitioned,  starting  at  the  leftmost  character,  into  segments  each  of  which 
will  comprise  a single  WET  entry  (a  segment  being  the  longest  string  storable 
in  a WET  entry).  The  last  segment  will  consist  of  the  remaining  character 
string  from  the  last  break  to  an  end  of  word  delimiter.  Continued  segments 
are  marked  by  inserting  a special  character  (e.g.,  a hyphen)  as  the  last 
character  of  the  WET  entry.  The  numeric  codes  assigned  to  each  word  segment 
are  then  recursively  encoded  from  TET  (Term  Encoding  Table)  entries  until  a 1 

single  numeric  code  representation  is  obtained.  Similarly  if  a term  is  too  : 

large  to  store  in  a single  TET  entry,  it  is  recursively  encoded  via  a single  ■: 

left  to  right  scan  until  a single  numeric  term  code  is  obtained.  Figure  6-2 
represents  the  typical  term  encoding  process, 

6.3  DECODING  MECHANISM 


An  integrated  decoding  table  is  maintained  by  the  Directory  Services 
Subsystem.  As  each  word  and  term  (and  word  and  term  fragments)  are  entered 
into  the  Word  and  Term  Encoding  Tables,  an  additional  entry  is  made  in  the  in- 
tegrated Term  Decoding  Table  (TDT) . When  term  or  wrrd  decoding  is  required 
(e.g.,  in  response  to  an  analyst  query  of  the  value  of  some  attribute),  basically 
an  inverse  encoding  algorithm  is  followed.  The  given  term  code  is  entered  in 


the  Initial  entry  in  a push  down  table.  A recursive  loop  Is  begun  in  which 
the  first  entry  in  the  push  down  table  Is  examined.  If  the  entry  has  the  Word 
Code  Indicator  bit  set,  then  the  entry  is  further  decoded  into  its  English 
text.  The  text  is  the  concatenated  with  any  previously  decoded  text.  A ’blank’ 
cb'^-^acter  is  added  to  the  text  if  the  word  is  not  marked  as  continued.  This 
entry  Is  then  popped  off  the  stack  since  it  is  completely  processed.  If  the 
entry  did  not  have  the  UCI  bit  set,  then  the  decoding  entries  are  retrieved  and 
entered  in  the  push  down  table  in  place  of  the  first  entry.  Another  Iteration 
in  the  loop  is  then  begun.  When  the  push  down  table  is  empty,  the  generated 
text  in  returned  to  the  caller. 


6-5 


REFERENCES 


KTIS  Users  Guide.  Foreign  Technology  Division,  May  1975. 

J.  Sable  and  S.  Forst:  Design  Concept  for  an  Augmented  Relational  In- 

telligence System  (ARIAS).  AUER-2022-TR-2,  August  1973  (RADC-TR-73- 
342/AD  773  189) 

I.  Goldhirsh  and  R.  Carson:  A Deductive  System  for  Intelligence 

Analysis.  AUER-2255-TR-1,  March  1976. 

J.  Sable  and  S.  Forst;  Needs  Analysis  For  Inference  Systems  at  FTD. 
RADC-TR-73-4,  January  1973  (AD  757  218) 

G.  Hendrix;  Expanding  the  utility  of  semantic  networks  through  par- 
titioning. Artificial  Intelligence  Group  Technical  Note  105,  SRI 
(June  1975). 


7-] 


CURRENT  STIS  STRUCTUllitE 


The  capabilities^  operating  characteristics  and  performance 
of  STIS  follow  largely  from  the  general  architecture  of  its  system  component** 
and  Its  data  structures.  The  general  architecture  of  STIS  and  Its  relation- 
ship to  the  on-line  and  batch  user  Is  shown  in  Figure  A-1.  STIS  Is  a modular 
system  in  which  user  requests  for  Information  services  may  pass  through  severa''. 
levels  of  translation  during  processing.  It  provides  a "general"  (non-appllca- 
tlon  specific)  language  called  IPL  (Interactive  Processing  Language)  for  the 
user  who  wants  to  "browse"  through  the  data  base  and  perform  his  own  analyses. 
Other  users,  whevse  analysis  requirements  have  been  normalized  can  be  provided 
with  "special  purpose"  languages  through  application  programs  written  in  COBOL 
(e.g.,  IPS)  and  FORTRAN  (e.g.,  lEAS).  The  HOL  (High  Order  Language)  programmer 
user  writes  a special  Program  Interface  Module  (PIM)  which  is  compiled  and  linked 
(collected)  with  the  application  program.  HOL  requests  for  STIS  services  are 
made  through  the  PIM,  which  Is  typically  a 5K  word  module  of  the  users  code. 

In  the  current  operation,  each  user  (on-line  or  batch)  must  have  his  own  "copy" 
of  STIS,  some  40K  words,  in  memory.  Large  user  programs,  such  as  lEAS  may  run 
from  85K  to  90K  words  (perhaps  reducible  to  50K  with  segmentation),  putting  a 
severe  limit  on  the  number  of  active  users  which  can  be  accommodated  In  the  four 
65K  word  memory  banks  available  to  users  In  the  1110.  A fundamental  goal  of  a 

near-term  optlmazatlon  effort  would  be  co  handle  multiple  users  with  a single  copy 
of  STIS. 

The  architecture  of  the  STIS  data  structure  can  be  described 
as  an  amalgamation  of  different  classical  data  structures.  It  can  be  called 
a Relational  Data  Network  in  that  it  is  composed  of  nodes  which  are  interre- 
lated through  binary  relationships  (and  their  converse)  using  a unique  Node 
Identifier  (NID)  as  a logical  link.  The  nodes  themselves  have  a variable 
hierarchic  format  in  which  common  elements  are  "factored"  to  avoid  redundancy 
within  the  node.  In  addition  to  control  data  embedded  at  various  levels  in 
the  node  structure,  the  basic  user  Information  Is  carried  in  attribute  name 
(A#) /attribute  value  format.  Multiple  va  les  are  permitted  for  each  attribute, 
along  with  warnings,  comments,  and  other  text.  The  current  STIS  1 node  Is  seen 
in  its  physical  and  logical  form  in  Figures  A-2  and  A-3  respectively. 
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Figure  A-1  Current  STIS  Architecture 
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Figure  A-2  Physical  Node  Structure 


GENERAL  DATA  BLOCK  STRUCTURE  FORMS 


The  3 general  forms  employed  to  store  key/data  entries  are  outlined  below; 


CN 

cn 

BCW 

3 

n 

3 

CQ 

KEY^/DATA^ 

KEY2/DATA2 

KEY  /DATA 
n n 

FORM  A 


3 
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to 


KEYj^/DATA^ 


KEY  JDATA, 


K£Y„/ 

DATA 
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FORM  B 


r-^r 
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s • 1 • 

(Q 

PQ 

Q 

0 

CC 

n 1 
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The  Block  Control  Words  (BCW's)  are  defined  as  follows  fcr  all  forms: 

T1  S3  S4  T3 

BCW  1 1 BNEXT  IbT  I SPARE  I BENTRY  I 

BNEXT  = next  available  word  in  this  block 

BT  = block  type  = 1 Indicating  this  is  a data  block 

BENTRY  = number  of  key/data  entries  in  this  block 


HI 

H2 

BCW  2 

SPARE 

i BFRWRD  1 

BFRWRD 

= block  nuniber  of  next 
(In  last  data  block, 

sequentially  forward  data  block. 
BFRWRD  = 0). 

HI 

H2 

BCW  3 

1 SPARE 

BN  [ 

BN  = this  block's  number 


The  Record  Control  Word*  (RCW'a)  are  defined  at  follows: 

FORM  A No  RCW  appears  within  tho  data  block  for  fixed  key  and 
fixed  data  records.  An  implicit  RCW  is  defined  In 
various  fields  of  the  File  Control  Table  for  this  file. 
Note  that  for  this  structure,  only  one  data  cntrj  may 
exist  for  a given  key  entry  (a  1 to  1 correspondence 
exists) . 


FORM  B 
RCW 


T1  T2  T3 

KLEN  I SPARE  I NKEY  I 


KLEN  ■ length  of  following  key  In  characters.  Can  be  used 
as  an  offset  to  data  entry  by  converting  to  words, 
rounding  up,  and  adding  1. 

NKEY  ° 'offset  to  next  key  in  block'  In  words.  This  la  a 
total  count  in  words  of  the  key  and  data  entries 
and  increased  by  1 to  compensate  for  the  RCW. 

Note  that  the  size  of  a variable  length  data  entry 
is  computed  as  the  difference  in  words  between 
'offset  to  next  key  'and'  offset  tu  data  entry'. 

This  implies  that  on  a retrieve  operation  for  a 
variable  length  data  entry,  the  record  returned 
to  the  user  could  be  up  to  5 characters  longer 
than  the  original  insertion  size  In  characters 
since  we  always  return  an  Integral  number  of  words. 

As  in  FORM  A above,  this  structure  only  permits  a 
1 to  1 correspondence  between  key  and  data  entries . 
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FORM  C 


T1  S3  S4  T3 

RCW  1 KLEN  Is  pare"  } DENTRYI  "nKCT“~1 

KI.EN  ■ length  of  following  key  in  characters  (as  in  FORM  B) 

NKEY  ^ 'offset  to  next  key  in  block'  in  words  (as  in  FORM  B) 

DENTRY  >•  nvunbcr  of  data  entries  that  exist  for  the  following 
key. 

This  structure  perwits  a 1 to  many  correspondence 
between  key  and  data  entries.  Note  that  use  of 
this  structur-^  carries  the  restriction  that  the 
data  entries  must  be  of  the  same  f ixed  length. 
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INDEX  BLOCK  STRUCTURE 


3 

CM 

3 

cn 

3 

3 

KEY^ 

3 

KEY2 

3 

KEY 

A 

0^ 

ct 

n 

T1  S3  S4 T3 


BKEXT 

BT 

SPARE 

BENTRY 

BNEXT  = next  available  word  in  this  block 

BT  = block  type  = 2,  Indicating  this  is  an  index  block 


BENTRY  = 

number  of  'kev 

' entries  in  this  block 

HI 

(12 

BCW  2 

I SPARE  1 

PFRWRD  1 

BFRWRD  = 

the  number  of 
depth  level  as 
(In  last  block 

the  next  physical  bl(x:k  at  the  same 
this  block.  (A  forward  pointer), 
of  any  level,  BFRWRD  = 0) 

HI 

H2 

BCW  3 

1 SPARE 

BN  ! 

BN  = this  block's  number 

T1  S3  H2 

XCW  r KLEN  ISPAREl  3DCMN  I 


KLEN  = length  of  followinfi  key  in  characters.  Can  be  used  as  an 
offset  to  next  key  by  converting  to  words,  rounding  up, 
and  add ing  1 . 

BDCWN  = block  number  of  next  lower  level  block  in  which  this  key 
range  is  further  expanded.  (At  lowest  index  level,  this 
field  points  to  the  actual  data  blocks). 


S PFXIFU:  KfY /IIAIA  ()M:.\N1/Ai  ION  TY1M.S 


nifri'  are  7 mcthcnls  for  organlrlnK  maiUpuiat  Inn  key/daia  tnirics  within  the 
iiccesa  package.  A deacrlptlon  of  each  along  with  tlu-  general  data  block  atruc- 
ture  einnloyed  follows: 
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iTiis  type  supports  a fixed  key  and  fixed  data  entry  each  of  arbitrary  character 
length.  Within  the  physical  data  block,  both  Che  key  and  data  entries  will  each 
be  positioned  to  begin  on  a word  boundary.  Entries  which  are  not  multiples  of  6 
characters  (1  word)  will  be  padded  with  binary  zeroes. 

When  Inserting  records  into  this  type  file,  the  user  will  specify  a 'key  entry 
area'  and  a separate  ’data  entry  area'.  Tlie  key  and  data  entries  can  be  thought 
of  as  being  logically  but  not  physically  connected: 
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KEY^ 

; DATA^ 
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KEY^ 

; DATA, 
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n 
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Uses 
FORM  B 


This  type  supports  a variable  length  key  entry  with  a fixed  length  data  entry 
each  of  arbitrary  character  length.  Within  the  physical  data  block,  both  key  and 
data  entries  will  each  be  positioned  to  begin  on  a word  boundary.  Entries  which 
are  not  multiples  of  6 characters  will  be  padded  with  binary  zeroes. 

The  user  must  specify  the  maximum  character  length  the  key  entry  may  assume  at 
file  definition  time.  Each  manipulative  command  also  requires  the  characCev. 
length  of  the  particular  key  entry  being  accessed  as  a formal  argument. 


This  type  supports  a fixed  length  key  entry  with  e variable  length  data  entry 
each  of  arbitrary  character  length.  Within  the  physical  data  block,  both  key 
and  data  entries  will  each  be  positioned  to  begin  on  a word  boundary.  Entries 
which  are  not  multiples  of  6 characters  will  be  padded  with  binary  zeroes. 

The  user  must  specify  the  maximum  character  length  the  data  entry  may  assume 
at  file  definition  time.  Each  manipulative  conmand  either  requlreo  the  char- 
acter length  as  a formal  input  argument  or  returns  the  character  length  rounded 
to  the  next  multiple  of  6 into  a formal  return  argument. 

TfPE  4 

Uses 

FORM  B 


This  type  supports  a variable  length  key  and  variable  length  data  entry  each  of 
arbitrary  character  length.  Within  the  physical  data  block,  both  key  and  data 
entries  will  each  be  positioned  to  begin  on  a word  boundary.  Entries  which  are 
not  multiples  of  6 characters  will  be  padded  with  binary  zeroes. 


The  user  must  specify  the  maximum  character  length  for  both  key  and  data  entries  1 

at  file  definition  time.  Each  manipulative  command  will  require  the  actual  key  ’ 

length  in  characters  as  a formal  Input  argument  and  either  actual  data  length 

in  characters  as  an  input  argument  or  will  return  the  character  length  rounded  to 

the  next  multiple  of  6 into  a return  argument.  I 


TYPE  5 


^■4 

rvi 

cn[  DATAj 

1 DATAj 

1 

5 

X 

Ji 

KEY2""  ^ 

-1  ■_ 

Utet  FORM  A 


This  type  also  siipporta  a fixed  key  and  fixed  data  entry  each  of  arbitrary  length 
i»s  in  TYPE  1,  However,  the  data  entry  will  be  poaitloned  on  a character  boundary 
inside  the  pnyaical  block.  Only  data  entries  which  are  not  multiples  of  6 char- 
acters will  be  padded  with  binary  zeroes. 

When  inserting  records  into  this  type  file,  the  user  will  specify  a single  'key/ 
data  entry  area*.  In  this  area,  the  user  will  have  packed  the  key  and  data 
entries  as  a contiguous  string  of  characters.  The  access  package  will  take  and 
position  this  contiguous  string  in  the  physical  data  block. 

For  *-etrieval  comaands,  the  access  package  will  locate  and  unpack  the  string  in 
the  physical  block  and  return  Just  the  data  entry  portion  into  a user  defined 
data  return  area  as  Is  normally  done  for  other  type  files. 


This  type  supports  a fixed  key  entry  witti  a multiple  number  of  fixed  data  entries. 
Within  the  physical  data  block,  the  key  and  each  data  entry  are  positioned  to  begin 
on  a word  boundary.  Entries  which  are  not  multiples  of  6 characters  will  be  padded 
with  binary  zeroes. 

Each  data  entry  is  uniquely  Identified  by  a cole  code  number  assigned  by  the  user 
(designated  in  figure  by  R^).  T^ere  may  only  exist  1 data  entry/role.  code/key 
entry.  The  role  code  is  a 4 bit  field  (left  justified)  embedded  in  the  first 
character  of  the  data  entry.  For  this  reason,  the  user  must  not  use  these  bits  as 
user  storable  data  bits.  The  access  package  will  merge  the  user  defined  role  code 
number  into  these  bits  when  storing  data  entries  and  strip  off  these  bits  when 
returning  a selected  data  entry  to  the  user.  The  data  entries  are  stored  in  the 
data  block  in  the  order  in  which  they  are  received.  Sequential  ordering  according 
to  increasing  role  code  number  is  not  maintained. 

Note  Chat  all  role  code  data  entries  must  be  of  Che  same  fixed  size  specified  at 
file  definition  time. 

TYPE  7 


Uses 
FORM  C 

This  type  supports  a variable  length  key  entry  with  a multiple  number  of  fixed 
data  entries.  The  same  comments  apply  hire  as  in  TYPE  6 above. 
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ACCESS  PACKAGE  PRIMITIVE  COMMANDS 


The  following  cooinands  are  used  independently  of  file  organization: 

1)  DEFNFJLE  (FCT,  Data  blk  size.  File  Type,  Key  length,  Data  length,  Role 
Coaas  Flag  < , Index  Filename,  Index  blk  size  ) 


This  cofnmand  defines  the  organization  and  parameters  for  the  file 
named  in  the  FCT. 


FCT  The  File  Control  Table  defined  and  residing  in  the  user's 

memory  area.  It  contains  the  name  of  the  file  to  be 
defined  in  its  first  2 words. 


Data  The  size  in  words  to  be  allocated  for  the  physical  data 

blk  size  This  must  be  a multiple  of  the  disc  prep  size 

(typically  112  words) . 


File  Specifies  the  organization  of  the  file  according  to  the 

type  of  key  and  data  entries  to  be  processed. 

" 1 Fixed  kev,  fixed  data 
<■  2 Variable  key,  fixed  data 

* 3 Fixed  key,  variable  data 

■ 4 Variable  key,  variable  data 
“ 5 Fixed  key,  fixed  data  packed 


Key 

Length 


Specifies  either  the  actual  key  length  in  characters  for 
fixed  key  files,  or,  the  maximum  key  length  for  variable 
key  files.  No  key  length  can  exceed  30"  of  the  total 
length  of  the  ph}sical  index  block. 


Data 

Length 


Specifies  either  the  actual  data  entry  length  in  characters 
for  fixed  dote  files,  or,  the  maximum  data  entry  length 
for  variable  data  files.  No  key/data  entry  pair  may  have 
a total  length  which  exceeds  the  physical  data  block  size. 
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Speciftt.'  whether  the  file  will  or  will  not  have  role 
codes  within  It  a 

= 0 no  role  codes  In  file 
0 role  codes  In  file 

If  role  codes  are  indicated  then  'File  Type'  laost  be 
= 1 or  = 2.  The  data  entries  must  be  fixed  In  length 
with  each  data  entry  equal  in  size  to  all  other  data 
entries . 

Index  filename,  Index  block  size 

These  are  optional  parameters  which  specify  that  the 
Index  blocks  are  to  be  stored  In  a separate  physical 
file  whose  12  character  name  Is  giver  In  'Index  filename'. 

'Index  block  size'  specifies  the  size  In  wards  to  oe 
allocated  for  the  physical  Index  blocks.  This  must  be 
a multiple  of  the  disc  prep  size. 

If  these  two  parameters  are  absent,  the  Index  blocks 
will  be  embedded  In  the  same  file  as  the  data  blocks. 

The  index  block  size  will  be  made  equivalent  to  the  data 
block  size. 

2)  OPEN  (FCT,  READ/WRITE  Flag) 

This  command  permits  a user  access  to  a particular  file. 

FCT  The  File  Control  Table  defined  and  residing  in  the  user's 

memory  area.  It  contains  the  nan?e  of  the  file  to  be 
opened  and  accessed  in  Its  first  1 words. 

READ/  Specifies  read/write  mode  for  this  file. 

WRITE 

Flag  = 0 reading  and  writing  permitted 

= 1 only  reading  permitted 


Bole 

Codes 

Flag 
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3)  CL0SE  (FCT,  Inform  area) 

This  coacand  closes  a particular  file  and  Inhibits  further  access 
to  that  file  by  the  same  user  without  a new  'OPEN' . 

FCT  The  File  Control  Table 

Inform  A seven  word  array  residing  In  the  user's  memory  area 
diTGd 

Into  which  statistical  information  will  be  placed.  The 
infcimatlon  will  be  relative  to  the  actual  creation  of 
the  file. 

The  Inform  area  will  contain  the  fcllcwing: 

word  I The  total  number  of  data  and  index  blocks  In  the  file 
iv  the  Index  blocks  are  embedded  in  the  file,  or,  the 
total  ..umber  cf  data  blocks  if  the  index  blocks  are 
maintained  in  a separate  file. 

word  2 The  total  number  of  index  blocks. 


word  3 The  total  number  of  data  block  overflows  thus  causing  a 
data  block  split. 

word  4 The  total  number  of  Index  block  overflows  thus  causing 
an  index  block  split. 

word  5 The  total  number  of  data  entry  records  read, 

word  6 The  total  number  of  data  entry  records  written, 

word  7 The  total  number  of  existing  data  entry  records. 


IJA  V L ■ I^VI'  i/.-.'1-.rn-K  ~ - -=  r»7»fW7^pCTWP5!J1P^ 


4)  INFORM  (FCT,  Inrorm  araf) 

This  command  gives  the  user  Information  about  a particular  file 
relative  to  the  execution  of  the  user's  last  'OPEN*  command. 

FCT  The  File  Control  Table 

Inform  The  description  is  given  under  'CLOSE' 
area  contents  of  the  'Inform  area'  will  be  a set  of 

numbers  relative  to  the  user's  last  'OPEN'.  At 
'OPEN'  time,  these  counters  are  reset  to  zero  and 
Increcaented/decrenented  for  each  user  action  on  this 
file.  Note  that  word  7 should  be  Interpreted  as  the 
number  of  Insertions  and  deletions  made  to  the  file. 
If  this  number  is  negative,  then  the  user  made  more 
deletions  then  insertions. 


5)  OPENAP 


This  consnand  'opens'  the  access  pa«.lcage  to  the  user.  It  sets 
up  contingency  processing  linkages  for  the  user.  The  user  must 
execute  this  command  only  once  before  all  other  access  package 
commands. 


6)  CLOSEAP 


This  command  'closes'  the  access  package  to  the  user.  It  clears 
all  locked  records  on  all  files  that  the  user  may  have  neglected 
to  close.  The  user  should  execute  this  command  once  before 
terminating  his  job. 
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Th''  follow^  D comm,  1 hijve  p.iramctfr  lists  wblcli  are  dependent  on  the  file 
organization.  They  are: 

1)  RDRAN  (I'CT,  Key  entry  area,  < Key  size  > Data  entry  area  <,  Data  size  >• 
<,  Role  >) 

This  command  retrieves  a data  entry  for  a given  random  key. 


FCT  The  I'.le  Control  Table 


Key 

entry 

area 


The  location  in  the  user's  memory  containing  tlie 
search  key. 


< Key  The  character  length  of  the'  key  if  a variable  '..ey  file. 
Size,  > 


Data 

entry 

area 


Tt>e  location  in  the  u.scr'.s  memory  where  the  data  entry 
will  be  placed. 


< ,Data  The  location  in  the  user's  memory  wliere  tl>e  size  of  the 
^ data  entry  (rounded  to  the  next  highest  multiple  of  b 

characters)  will  be  placed  for  a variable  data  file. 


< , For  a file  with  role  codes,  the  role  number  o';  tlie 

data  entry  to  be  retrieved, 

2)  RD  SKQ  (FCT,  Key  entry  area  ,<  Key  size,>  Data  entry  area  ' , Data  si>,e">) 


This  command  retrieves  the  data  entry  for  the  next  sequentially 
ascending  key  for  a given  random  key, 

FCT  The  File  Control  Table 


Key 

entry 

area 


The  location  in  the  user's  memory  containing  the  key  which 
causes  the  search  for  the  next  ascending  key.  The  new  key 
when  found  will  be  placed  in  thi.s  area. 


< Key  The  character  length  of  the  input  key.  This  is  replaced 
size,:>-  character  length  of  the  retrieved  key  for  variable 

key  files. 


Data  The  location  in  the  user's  memory  where  the  data  entry  will 

be  placed. 

area 
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< . 
Data 

s i zc  ■> 


Tho  location  in  the  user’s  memory  where  thi’  size  of  the 
data  entry  (rounded  to  the  next  hi>>hest  multiple  of  6 
characti-rs)  will  be  placed  for  a variable  data  fill'. 


RIH.ISTRAN  (FCT,  Key  entry  area,^  Key  size,'*  Dni.i  entry  area,  -v  of  entries) 


This  command  retrieves  the  data  entries  tor  all  the  roles  tliat  may 
exist  for  a given  random  key. 

rci  ilie  File  Control  I able 


Key 

entry 

area 


The  location  in  the  user's  memory  containing  the  search 

key . 


Key  The  character  length  ol  the  key  lor  a variable  key  file, 
size,  • 


Data 

entry 

area 


The  location  in  the  user's  memory  where  all  the  data 
entries  found  will  be  placed. 


o f 

entries 


The  location  in  the  user's  memory  where  the  number  of 
data  entries  found  and  returned  to  the  data  entry  area 
will  be  placed. 


DI.lsrSKQ  ('-CT,  Key  entry  area,  Key  slze,t>-  Data  entry  area,  •••  of  entries) 

This  command  retrieves  the  data  entries  for  all  the  roles  that  may 
exist  for  the  next  sequentially  ascending  key  for  a given  random  key. 

FCi  The  File  Control  Table 


Ke  y 

entry 

area 


The  location  in  the  user's  memory  containing  the  key 
which  causes  the  search  for  the  next  ascending  key.  The 
new  key  when  found  will  be  placed  in  this  area. 


Key  The  character  length  of  the  input  key.  This  is  replaced 
s i ?6 

' by  the  character  length  of  the  retrieved  key  for  variable 

key  files. 
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The  location  In  the  user's  memory  where  all  the  data 
entries  found  will  he  placed. 

The  location  In  the  user's  memory  where  the  number  of 
data  entries  found  and  returned  to  the  data  entry  area 
will  he  placed. 

5)  KDRANLK  (FCT , Key  area  ,<  Key  size,  > Data  area  < , Data  six.e>  <,  Role  >) 

6)  RDSRQLK  (FCT,  Key  area,<Key  size,  > Data  area  < , Data  slze>) 

7)  RDLISTRANDK  (FCT,  Key  area,  < Key  si'/.e,^  Data  area,  # of  entries) 

8)  RDLISTSEQLK  (FCT,  Key  area  ,<  Key  size,  > Data  area.  It  of  entries) 

These  four  commands  have  parameter  lists  whicli  are  defined  in  the 
same  manner  as  the  standard  retrievai  functions  1 through  4.  They 
also  perform  the  same  function  but,  in  addition,  a check  is  made 
to  determine  if  the  retrieval  entry  is  locked  by  other  i.scrs.  If 
the  entry  is  locked,  it  Is  not  returned  and  an  indication  of  tills 
is  passed  to  the  caller.  If  the  entry  Is  not  locked,  then  it  is 
returned  to  the  caller  and  a logical  lock  is  placed  on  the  key 
entry.  Each  user  may  place  an  arbitrary  number  (defined  at  system 
generation)  of  logical  locks  on  each  file,  A lock  can  only  he 
removed  by  performing  a MODIFY  or  DELETE  command  utilizing  the 
locked  key.  The  same  user  wlio  initially  locked  the  entry  must 
unlock  it. 

The  normal  retrieval  commands  1 through  4 do  not  check  and  do  not 
set  locks.  Thus,  they  act  as  simple  "intjuiry  only"  requests. 

9)  INSERT  (FCT,  Key  entry  area,  < Key  s ! e,>  Data  entry  area  <,  Data  size'> 

< , Role  > ) 

This  command  adds  either  a key/data  entry  pair  or  a data  entry 
qualified  by  role  number  to  a file, 

FCT  The  File  Control  Table 


Data 

entry 

area 

it  of 
entr  ies 
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Key 

entry 

area 


The  location  in  the  user's  memory  area  containing  the 
key  to  be  inserted,  nr  in  tne  case  of  a fIL?  with  role 
codes,  possibly  the  search  key.  If  a role  code  is 
specified  in  the  parameter  list,  a search  is  made  to 
find  the  key  within  the  file.  If  the  key  is  found,  then 
a new  data  entry  insertion  only  is  attempted.  If  the 
key  is  not  found,  then  the  key  is  also  inserted  as  well 
0j  the  specified  role  code  data  entry. 


•cKey  rhe  character  lengtl\  of  the  new  key  If  a variable  kev  'ile. 

slae,  :> 


Data 

entry 

area 


The  location  in  ti\e  user's  memory  containing  the  new  data 
entr  y . 


■<  , Data 
sl?;e  >- 


The  character  length  of  the  new  data  entry  if  a variable 
data  file. 


C,  Role>The  role  code  number  that  is  to  be  stored  fand  subsequently 
used  as  a secondary  key)  along  with  the  new  data  entry  if 
the  file  is  defined  as  one  having  role  codes. 


NOTE:  See  description  of  TYPE  5 file  organization. 

10)  DELETE  (FCT,  Key  entry  area<^,  Key  size><;,  Role  > ) 

This  command  deletes  either  a key/data  entry  piir  or  a data  entry 
qualified  by  role  code  number  from  a file. 


FCT  The  File  Control  Table 


Key 

entry 

area 


The  location  in  the  user’s  memory  area  containing  the 
search  key. 


< . 

Key 

Size  > 


The  character  length  of  the  key  entry  if  a variable  key 
file. 
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<:  , The  data  «n'. ry  apcclfied  by  this  role  code  number  Is  to 

Role  > delated  for  a file  defined  with  role  codes.  If  more 

than  one  data  entry  exists  for  the  given  key,  then  only 
the  specified  role  data  entry  Is  deleted.  If  tiie  only 
data  entry  that  exists  for  the  given  key  is  that  which  la 
specified  by  the  role  parameter  then  that  data  entry  and 
the  key  entry  are  both  deleteo. 


11)  MODIFY  (FCT,  Key  ffntry  area,  ^ Key  slxe,:>  Data  entry  area  Data  r.lze> 
< , Role>) 


This  command  updates  a data  entry  possibly  specified  by  a role 
number  for  a given  random  key. 


FCT  The  File  Control  Table 


Key 

entry 

area 


The  location  In  the  user's  memory  area  containing 
the  search  key. 


Key  The  character  length  of  the  key  enfy  If  a variable 

slze,>.  , 

key  file. 


Data 

entry 

area 


The  location  In  th,i  user's  memory  area  containing  the 
•lew  data  entrv  \.'hlch  will  be  used  to  overwrite  the  old 
data  entry. 


Data 
size  >• 


The  cl'.aracter  length  nt  rhe  rev  dara  entry  If  a variable 
data  file. 


< . 

Role  >• 


The  role  number  of  the  old  data  entry  to  i.e  updated  if  a 
role  code  file. 
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FILE  TYPE  VERSlfS  APPLICABLE  COMMAND  LIST 

The  followlns  !■  4 list  of  comnends  with  their  respective  parameter  lists  for 
each  file  type; 


ALL  TYPES 


DEFNFILE  (FCT,  Data  blk  size,  File  Type,  Key  length,  Data  length. 
Role  Flat;<,  Index  Filename,  Index  blk  slse>} 

OPEN  (FCT,  Read /Write  Flag; 

CLOSE  (FCT,  Inform  area) 

INFORM  (FCT.  Inform  area) 

OPENAP 

CLOSEA? 


7)’ PE  1 


TYPE  2 


RDRAN  (FCT,  Key  entry  area,  Data  entry  area) 
RDSBQ  (FCT,  Key  entry  area.  Data  entry  area) 
RDRANLK  (FCT,  Key  entry  area.  Data  entry  area) 
RDSBQLK  (FCT,  Key  entry  area.  Data  entry  area) 


INSERT  (FCT,  Key  entry  area, 
DELETE  (FCT,  Key  entry  area) 
MODIFY  (FCT,  Key  entry  area. 


RDRAN  (FCT,  Key  entry  area, 
RDSEQ  (FCT,  Key  entry  area, 
RDRANLK  (FCT,  Kfcy  entry  ar^a, 
RDSEQLK  (FCT,  Key  entry  area, 
INSERT  (FCT,  Key  entry  area, 
DELETE  (FCT,  Key  entry  area, 
MODIFY  (FCT,  Key  entry  area, 


Data  entry  area) 
Data  entry  area) 


Key  size.  Data  entry  area) 
Key  size.  Data  entry  area) 
Key  size.  Data  entry  area) 
Key  size.  Data  entry  area) 
Key  size.  Data  entry  area) 
Key  size) 

Key  size,  Data  antry  area) 
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TYPE  3 


RDRAN 

(FCT, 

Key 

entry 

area , 

Data  entry  area.  Data  size) 

RDSEQ 

(FCT, 

Key 

entry 

area. 

Data  entry  area.  Data  size) 

RDRANLK 

(FCT, 

Key 

entry 

area , 

Data  entry  area,  Data  size) 

RDSEQLK 

(FCT , 

Key 

entry 

area , 

Data  entry  area.  Data  uize) 

INSERT 

(FCT, 

Key 

entry 

area , 

Data  entry  area.  Data  size) 

DELETE 

(FCT, 

Kev 

entry 

area) 

MODIFY 

(FCT, 

Key 

entry 

area. 

Data  entry  area.  Data  size) 

TYPE 

Jj. 

RDRAN 

(FCT, 

Key 

entry 

area , 

Key  size,  Data  entry  area.  Data 

size) 

RDSEQ 

(FCT. 

Key 

entry 

area. 

Key  size,  Data  entry  area.  Lata 

size) 

RDRANLK 

(FCT, 

Key 

entry 

area , 

Key  size.  Data  entry  area.  Data 

; i ze) 

RDSEQLK 

(FCT, 

Key 

entry 

area , 

Key  size.  Data  entry  area.  Data 

size) 

INSERT 

(FCT, 

Key 

entry 

area. 

Key  size.  Data  entry  area,  Data 

size) 

DELETE 

(FCT, 

Key 

entry 

area , 

Key  size) 

MODIFY 

(FCT, 

Key 

entry 

area , 

Key  size.  Data  entry  area.  Data 

size) 

TYPE 

_5 

RDRAN 

(FCT, 

Key 

entry 

area. 

Data  entry  area) 

RDSEQ 

(FCT, 

Key 

entry 

area , 

Data  entry  area) 

RDRANLK 

(FCT, 

Key 

entry 

area , 

Data  entry  area) 

RDSEQLK 

(FCT, 

Key 

en  try 

area , 

Data  entry  area) 

INSERT 

(FCT, 

KEY /DATA  entry  ^ 

area)  See  TYPE  5 file  description 

DELETE 

(FCT, 

Key  entry 

area) 

MODIFY 

(FCT, 

KEY /DATA  entry 

area) 

TYPE 

_6 

RDRAN 

(FCT, 

Key  entry 

area. 

Data  entry  area.  Role) 

RDLISTRAN  (FCT,  Key  entry  area.  Data  entry  area,  # of  entries) 
RDLISTSEQ  (FCT,  Key  entry  area.  Data  entry  area,  # of  entries) 
RDRANLK  (FCT,  Key  entry  area.  Data  entry  area.  Role) 

RDLISTRAMLK  (FCT,  Key  entry  area.  Data  entry  area,  # of  entries) 
RDLISTSEQIJC  (FCT,  Key  entry  area.  Data  entry  area,  # of  entries) 
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TYPE  / 


INSERT 

(FCT, 

DELETE 

(FCT, 

MODIFY 

(FCT, 

RDRAN 

(FCT, 

RDHSrRAN 

(FCT, 
# of 

RDLISTSEQ 

(FCT, 
^ of 

RDRANLK 

(FCT, 

RDLISTRANLK 

(FCT, 
# of 

RDLISTSEQLK 

(FCT, 
# of 

INSERT 

(FCT, 

DELETE 

(FCT, 

MODIFY 

(FCT, 

Key  entry  area,  Data  entry  area,  Role) 
Key  entry  area,  Role) 

Key  entry  area.  Data  entry  area,  Role) 


Key  entry 

area , 

Key 

size , 

Data 

entry 

area. 

Role) 

Key  entry 
entries ) 

area. 

Key 

size , 

Data 

entry 

area. 

Key  entry 
entries) 

area , 

Key 

size, 

Data 

entry 

area, 

Key  entry 

area. 

Key 

size. 

Data 

entry 

area. 

Role) 

Key  entry 
entries) 

area , 

Key 

size , 

Data 

entry 

area. 

Key  entry 
entries ) 

area, 

Key 

size , 

Data 

entry 

area. 

Key  entry 

area. 

Key 

size, 

Data 

entry 

area. 

Role) 

Key  entry 

area , 

Key 

size. 

Role 

) 

Key  entry 

area , 

Key 

size. 

Data 

entry 

area. 

Role) 
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ERROR  CODES 


f! 


The  follotfLn)?  codes  comprise  a complete  list  of  error  conditions: 


Error 


Cause 


1. 

2. 

3. 

4. 

5. 


6. 
7 . 
8. 

9. 

10. 


11. 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


19. 

20. 


Access  package  .ilreadv  in  i l i a 1 i /.ed  . Request  Ignored. 
Access  pack.ige  not  f n I L I a 1 i 'ed  . Run  lerml\i.ated  . 

No  sncli  lunction.  Reqiie  i luiored  . 

Incorrect  mimiier  ot  arguments  tor  lunction.  Request 
Ignored . 

rhe  I'lle  has  been  de  l ined  by  another  concurrent  run 
or  a .second  attempt  is  being  made  by  the  calling 
program  to  redeflna  • !te  tile.  Reque.st  Ignored. 

Data  block  size  exceeds  maximum.  Request  Ignored. 

Key  length  size  exceeds  maximum.  Request  ignored. 

Data  length  size  exceeds  maximum.  Request  ignored. 

The  key/data  format  type  does  not  exist,  i'equest 
Ignored . 

Role  codes  not  permitted  for  key/data  type  defined. 
Request  ignored. 

Data  block  size  less  than  minimum.  Request  ignored. 

Key  length  size  less  than  minimum.  Request  Ignored. 

Data  lengtn  size  less  than  minimum.  Request  Ignored. 

Index  file  not  assigned  properly  or  Internal  CSF$ 
syntax  error.  Request  ignored. 

Index  block  size  exceeds  maximum.  Request  ignored. 

Data  block  size  not  a multiple  of  disc  prep  size. 
Request  Ignored. 

Index  block  size  less  than  minimum.  Request  Ignored. 

Index  block  size  not  a multiple  of  disc  prep  size. 
Request  ignored. 

Data  file  not  assigned  properly  or  Internal  CFS$ 
syntax  error.  Request  Ignored. 

Pile  control  table  full  indicating  maximum  number  of 
files  are  open.  Request  Ignored. 
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I 


Error^ 


Cause 


21.  No  buffer  space  a-  ailable  for  file.  Request  ignored. 

22.  Attempt  to  close  a file  which  is  already  closed. 
Request  ignored. 

23.  Attempt  to  close  a file  which  has  not  been  opened. 
Request  ignored. 

24.  The  file  cannot  be  accessed  since  it  no  longer  ap- 
pears in  the  internal  File  Control  Table.  Probable 
system  software  malfunction. 

25.  No  statistics  gathered  since  the  file  has  not  been 
opened , 

26.  Attempt  to  read  a file  which  has  not  been  opened. 
Request  ignored. 

27.  Role  code  argument  out  of  range.  Request  ignored. 

28.  The  file  is  empty.  Request  ignored. 

29.  Block  number  read  not  block  number  desired. 

Integrity  of  file  destroyed. 

3C.  Block  type  read  not  block  type  desired.  Integrity 

of  file  destroyed. 

31.  No  record  exists  for  the  givei.  key. 

32.  A RDSEQ  request  not  permitted  on  a file  containing 
role  codes. 

33.  A 'Reed  List'  type  request  not  permitted  on  a file 
without  role  codes. 

34.  End  of  file  reached  while  performing  a sequential 
read. 

35.  Attempt  to  'change'  a file  declared  'read  only'. 

36.  File  is  being  initially  loaded.  No  requests  permitted 
by  other  users . 'Insert'  only  by  originator  of  load. 

37.  Attempt  to  ' isert  a key/data  record  for  which  the 
key  portion  already  exists.  Also  for  a file  with 
role  codes,  the  key  and  role  code  already  exist. 


Error  if 


Cause 


38.  Attempt  to  Insert  a key/data  record  v?hose  total 
length  exceeds  the  data  block  size.  For  a file 
with  role  codes,  the  total  length  includes  all 
existing  role  code  entries. 

39.  A non-ascending  key  was  given  during  an  initial 
load  insertion.  Request  ignored- 

40.  Attempt  to  open  a file  that  is  already  open. 
Request  ignored. 

41.  Record  is  currently  locked  by  another  user. 

42.  Maximum  number  of  users  are  active.  Cannot 
support  another. 

43.  User  is  not  active  witltin  rlie  access  package. 
Request  ignored. 

44.  Maximum  number  of  records  already  locked  by  this 
user.  Record  returned  to  user  but  not  locked. 
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ACCESS  PACKAGE  INTERNAL  TABLES  AND  CONTROL  BLOCKS 


The  following  is  a layout  and  description  of  the  various  core  tables  and 
control  blocks  used  by  the  peripheral  file  access  package  (PFAP). 


1 . THE  PFAP  COMMON  FILE  CONTROL  TABLE  OR  PFAPFCT 


PFAPFCT  LOCK  WORD 

ENTRY  1 

ENTRY  2 

] 

ft 

• 

ft 

• 

ENTRY  MAXFCT 

FCTSZE 


FCTSZE 


FCTSZE 


Table  B-1  The  PFAPFCT 


The  PFAPFCT  shown  in  Table  B-1  is  used  by  the  access  package  to 
control  the  activities  on  each  data  file  which  is  "opened"  for  access  by  any 
user.  The  table  is  partitioned  into  a fixed  number  of  entries  determined  by 
the  variable  MAXFCT  at  assembly  time.  Each  entry  is  defined  to  be  of  size 
FCTSZE.  Access  into  the  table  is  controlled  by  a "lock"  word  (a  Test  and 
Set  "queue"  type  word).  Each  new  file  which  is  opened  by  a user  is  entered 
into  the  first  available  "entry"  space  in  the  PFAPFCT.  When  a file  is  no 
longer  needed  by  any  user,  its  entry  position  is  cleared  for  re-use. 

Table  B-2  is  a layout  of  an  individual  "entry"  in  the  PFAPFCT. 
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0 

'this  ENTRY' 

LOCK  WORD 

1 

DATA 

2 

FILE  NAFE 

3 

I/O 

4 

PACKET 

5 

AREA 

6 

7 

NUSERS 

8 

SPARE  I FT 

DBLSZE 

IBLSZE 

9 

SPARE 

KLLN 

DLEN 

C 1 

10 

OFNXKY 

DBLSEC 

IBLSEC 

11 

NBLKS 

12 

NIBLKS 

13 

NDBLOV 

14 

NIBLOV 

15 

NREAD 

16 

NWRITE 

17 

NRECDS 

18 

HHIGH 

19 

NLEV5L 

20 

INDEX 

21 

FILE  NAFffi 

22 

I/O 

23 

PACKET 

24 

AREA 

25 

26 

USTIBL 

LASTDBL 

27 

HIBUFF 

SCRBUFF 

28 

SPARE 

DATP.UFF 

29 

£ 1 SPARE 

ILSZ 

E 

1 ILKYADR  1 

30 

ILRUNID  1 

31 

, 

RECORD 

, 

LOCK 

• 

AREA. 

FCTSZE 

table  B“2 

Layout  of  an  entry  in  the  PFAPFCT 


B-26 


IW' 


“ ■’W'-WM  ■'rnrwf  rp'VT’^-  ••^T!  rT'»B^'s?Tg?v#^r?^rffai^i^:>j|ii!V^ 


Deflnliitons  for  variable  names  shown  in  the  "PFAPFCT  ENTRY" 
layout  are  as  follow^: 


NUSERS 

FT 

DBL3ZE 

IBLSZE 

RC 

KLEN 

DLEN 

OFNXKY 


DBLSEC 

IBLSEC 

NBLKS 

NIBLKS 

NDBLOV 

NIBLOV 

NREAD 


number  of  concurrent  users  who  have  this  file 
currently  open. 

file  type,  a iiumber  from  1 to  7 described  under 
"General  File  Organization"  and  DEFNFII£ 
primitive  command.  (6  bits) 

physical  data  block  size  in  words.  (12  bits) 

physical  index  block  size  in  words.  (12  bits) 

role  code  flag,  a 1 bit  field  when  set  indicates 
file  has  role  codes  and  FT  field  must  be  6 or  7, 
when  reset  Indicates  file  has  no  role  codes  and 
FT  may  be  1 through  5. 

The  maximum  key  length  in  characters  for  variable 
key  files  (FT  = 2,  4,  or  7)  or  the  standard  key 
length  for  fixed  key  files  (FT  = 1,  3,  5 or  6). 

(12  bits) 

The  maximum  data  length  in  characters  for  variable 
data  files  (FT  = 3 or  4)  or  the  standard  data 
length  for  fixed  data  files  (FT  = 1,  2,  5,  6,  7). 
(12  bits) 

Used  as  an  "offset  to  next  key"  length  in  words 
for  files  with  FT  = 1 or  5.  Since  no  Record 
Control  Words  are  stored  in  data  blocks  for  these 
files,  this  field  provides  a convenient  incremental 
value  to  skip  from  one  key/data  entry  to  another. 
(12  bits) 

number  of  Fastrand  sectors  necessary  to  hold  a 
physical  data  block.  (12  bits) 

number  of  Fastrand  sectors  necessery  to  hold  a 
physical  index  block.  (12  bits) 

total  number  of  data  and  index  blocks  within  ri  file 
if  the  index  blocks  are  embedded  within  the  data 
file  or,  the  total  number  of  data  blocks  if  the 
index  blocks  are  stored  in  a separate  index  file. 

total  number  of  index  blocks  for  this  file. 

total  number  of  data  block  overflows  (which  caused 
a block  split  to  occur). 

total  number  of  index  block  overflows  (which  caused 
a block  split  to  occur). 

total  number  of  key/data  entries  read. 
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NWRITE 

NRECDS 

NHIGH 

NLEVEL 

LASTIBL 

LASTDBL 

HIBUFF 

SCRBUFF 

DATEUFF 

IL 

ILSZE 

ILKYADR 

ILRUNID 


total  number  of  key/data  entries  written. 

total  number  of  data  entries  within  the  file. 

the  number  of  the  highest  level  Index  block. 

the  number  of  index  levels  supporting  this  file. 

the  number  of  the  last  accessed  index  block  which 
resides  in  the  scratch  index  buffer.  (18  bits) 

the  number  of  the  last  accessed  data  block  which 
resides  in  the  data  block  buffer.  (18  bits) 

address  of  the  highest  level  index  block  buffer. 

(18  bits) 

address  of  the  scratch  index  block  buffer. 

(18  bits) 

address  of  the  data  block  buffer.  (18  bits) 

"initial  load"  flag,  a 1 bit  field  when  set 
indicates  this  file  is  being  initially  loaded  by  a 
unique  user . 

computed  "initial  load"  size  in  words.  This  value 
is  dependent  on  DBLSZE.  The  standard  load  factor 
percentage  is  defined  by  LODFAC  at  assembly  time. 
Then  ILSZE  = DBLSZE*LODFAC . (12  bits) 

relative  address  of  the  last  key  entered  in  the 
data  block  buffer.  This  field  is  used  when  checking 
for  sequentially  ascending  keys  at  initial  load 
time.  (12  bits) 

the  generated  "runid"  of  the  user  who  initiated  the 
"initial  load"  of  this  file.  All  other  users  are 
prohibited  from  performing  any  access  to  this  file 
during  an  "initial  load." 


Table  B-3  is  an  expansion  of  the  layout  of  the  RECORD  LOCK  AREA  within 
an  "entry"  of  the  PFAPFCT. 


LKENTRY 


LKBLCK 

MAXLOCKS 

MAXUSERS 


the  sequential  position  number  within  the  data 
block  of  the  key  that  is  locked.  Also  known  as 
the  entry  number.  For  a role  code  file,  the  key 
lock  extends  across  all  data  entries  stored  against 
the  key.  (12  bits) 

the  number  of  the  data  block  in  which  the  locked 
key  occurs.  (18  bits) 

maximum  number  of  records  that  may  be  simultaneously 
locked  by  any  user  on  any  one  file.  This  is  a 
variable  defined  at  assembly  time  and  extends  across 
all  files  opened  to  the  access  package. 

maximum  number  of  concurrent  users  that  can  be 
supported  by  the  access  package.  This  is  also  a 
variable  to  be  defined  at  assembly  time. 
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Jl 


LKENTRY 


SPARE 


LKBLCK 


USER  #1 
LOCK  Area 


304WAXLOCKS 

30+(MAXL0CKS+l) 


LKENTRY 


SPARE 


LKBLCK 


N 


USER  #2 
LOCK  Area 


30+(2*MAXL0CKS) 


30f(((MAXUSERS-l) 

*MAXLOCKS)+l) 


LKENTRY 


SPARE 


LKBLCK 


USER  #MAXUSERS 
LOCK  Area 


FCTSZE 


TABLE  B-3 

Lock  Area  within  an  entry  of  the  PFAPFCT 
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FCTSZE  total  size  of  an  entry  In  the  PFAPFCT.  A variable 

defined  at  assembly  time  as  FCTSZE  " 30  + 
(MAXLOCKS*MAXUSERS) 

An  entry  In  the  PFAPFCT  is  considered  to  be  available  If  the  Data 
Filename  words  contain  binary  zeros.  The  "next  available  entry"  Is  considered 
to  be  the  first  entry  encountered  which  has  its  Data  Filename  words  set  as 
binary  zeros. 

If  the  index  blocks  are  embedded  in  the  data  file,  then  the  Index 
Filename  words  will  w ntain  the  same  name  as  the  Data  Filename  words.  The  l/O 
accesses  will  still  be  controlled  through  the  Index  File  packet  as  If  the  Index 
filename  were  unique. 

Access  to  each  "entry"  In  the  PFAPFCT  is  controlled  by  a "lock"  word 
(a  Test  and  Set  "queue"  type  word).  Thus  there  are  two  levels  of  control  into 
the  PFAPFCT;  one  at  the  table  level  to  prevent  conflicts  when  deleting  and 
inserting  whole  "entrie'  and  one  at  the  "entry"  level  to  prevent  conflicts 
between  concurrent  usev.  i the  same  file. 

2.  THE  RUNID  TABLE 

The  RUNID  Table  Is  s list  of  the  generated  user  "runld"  names  obtained 
from  each  user's  PCT.  Each  user  who  performs  an  OPENAP  command  has  an  entry 
made  Into  the  next  avallabx,  slot  in  the  table.  Each  user  is  removed  from  this 
table  when  he  performs  a CLOSEAP. 

For  commands  involving  testing  and/or  setting  of  record  locks  (such  as 
RDRANLK,  DELETE,  etc.),  the  user's  RUNID  Is  obtained  from  his  PCT,  found  In  the 
RUNID  table,  and  the  resulting  relative  table  location  used  as  an  index  Into  the 
'record  lock  area"  of  the  PFAPFCT  entry  for  the  file  being  accessed. 

Access  to  the  RUNID  Table  is  controlled  by  a "lock"  word  (a  Test 
and  Set  "queue"  type  word).  It  is  used  to  prevent  conflicts  when  users  are 
added  or  deleted  from  the  table. 

Table  B-4  is  a layout  of  the  RUNID  Table. 


B-30 


3. 


THE  CO^lMON  BUFFER  TABLE  OR  CBT 


The  CBT  functions  as  a contiguous  buffer  pool  out  of  which  each  file 
that  is  currently  opened  has  assigned  to  it  an  area  large  enough  to  support 
X indsx  block  buffers  and  1 data  block  buffer 


Table  B-5  shows  the  layout  of  the  CBT. 


lASTGBT  ■ siae  in  words  of  the  CBT  defined  at  assembly 

time.  It  should  be  computed  as  lASTCBT  ■ 
HAXFCT*3*BUFMEAN  where  MAXFCT  is  the  maximum 
number  of  file  entries  in  the  PFAPFCT  and  BUFMEAN 
is  the  probable  mean  size  of  the  data  and  Index 
blocks  to  be  used  within  all  files. 


h.  THE  AVAILABLE  BUFFER  TABLE 


The  AVLBT  is  a table  of  addresses  and  word  lengths  defining  those  areas 
in  the  CBT  which  are  available  for  use.  When  a file  is  closed  and  no  longer 
needed  for  any  other  user,  Che  buffer  space  must  be  returned  to  the  pool.  Since 
the  buffer  space  was  allocated  on  a first  in,  first  out  basis,  the  CBT  is 
likely  to  become  fragmented  if  files  are  closed  (and  not  needed  by  other  users) 
on  a random  basis.  Initial  buffer  allocation  is  controlled  by  a variable  called 
NEXTCBT  which  contains  the  next  available  relative  CBT  address  (initially  0). 

If  the  difference  between  LASTCBT  and  NEXTCBT  is  large  enough  to  hold  the 
requested  buffer  needs,  then  the  absolute  CBT  address  is  generated  and  returned 
to  the  caller.  NEXTCBT  is  then  increased  by  the  number  of  words  just  allocated. 
However  when  space  is  returned  NEXTCBT  cannot  easily  be  modified,  so  the  AVLBT 
is  used  to  point  to  the  fragmented  free  space.  If  the  difference  between  LASTCBT 
and  NEXTCBT  is  too  small  to  satisfy  a buffer  request,  then  the  AVLBT  is  searched 
to  find  an  entry  whose  "#  of  words"  field  is  large  enough  to  satisfy  the  caller's 
request  The  appropriate  address  is  passed  to  the  caller  and  adjustments  made 
in  the  AVLBT  entry  to  compensate  for  the  size  needed, 

VJhen  space  is  returned  to  the  AVLBT,  an  attempt  is  made  to  find  an 
entry  whose  "next  available  CBT  address"  field  is  contiguous  to  the  "ending 
buffer  address"  of  the  space  being  returned.  If  such  an  entry  is  found  then  the 
AVLBT  entry  is  modified  to  include  the  new  space  being  returned. 
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0 

1 


BUFFER 

POOL 

SPACE 


USTCBT-1 

USTCBT 


TABLE  B-5 

The  Comnon  Buffer  Table 


Acceai  to  the  AVLBT  and  in  general  to  allocation  and  ralaaaa  of 
space  In  the  CBT  is  controlled  through  a "lock"  word  (a  Test  and  Set  "queue" 
type  word) . 

Table  B-6  is  a layout  of  the  AVLBT. 

Definitions  I'or  variable  names  shown  in  the  AVLBT  layout  are  as 

iol lows : 


AVWRDS 

NXAVCBT 

AVLBTSZE 


number  of  available  words  in  the  CBT  fragment 
pointed  to  by  NXAVCBT.  (IB  bits) 

relative  address  in  the  CBT  of  the  next  available 
fragment.  (IB  bits) 

maximum  number  of  entries  In  the  AVLBT.  This 
variable  is  defined  at  assembly  time. 


5.  THE  OVERFLOW  BUFFER  TABLE  OR  OBT 


The  OBT  is  used  as  a working  buffer  area  whenever  a data  block  or 
index  block  split  occurs  due  to  insertion  of  data  causing  an  overflow  situation. 
The  OBT  is  also  used  as  a I/O  packet  area  for  DEFNFILE  commands. 

Access  to  the  OBT  is  controlled  through  a "lock"  word  (a  Test  and 
Set  "queue"  type  wotd) . The  lo:k  word  is  generally  used  to  queue  more  than 
1 block  aplit occuring  concuirently.  The  size  of  the  OBT  is  defined  at  assembly 
time  as  OBTSZE  ■ 2*BUFMAX  where  BUFMAX  is  the  maximum  size  in  words  of  any 
index  or  data  block  likely  to  be  defined  for  any  file. 

Table  B-7  ts  a layout  of  the  OBI, 

6.  THE  OBT  OVERFLOW  AREA 

The  OBT  has  an  overflow  ars  which  again  is  used  during  the  block 
split  procedure.  This  area  is  used  to  hold  the  Record  Control  Wcrd(s)  (RCW) 
and  key(s)  which  need  be  inserted  into  the  next  successively  higher  index  block. 
At  the  data  block  level,  a n.axliiium  of  2 keys  may  be  entered  Into  this  area  while 
at  the  index  block  level,  only  1 key  may  be  entered  due  to  the  size  restrictions 
placed  on  key  and  data  lengths. 

Table  B-8  shows  a layout  of  the  OBT  OVERFLOW  AREA. 
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TABLE  B-8 

The  OBT  Overflow  Area 
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Definitions  for  variable  names  are  as  follows: 


NKYSAN 

SAVSZE 

RCWADR 

OBTOVSZE 


number  of  keys  being  saved  in  the  area  while  a 
block  split  is  being  performed. 

total  number  of  words  (Doth  key(s)  and  RCW(s)) 
being  saved  during  a block  split. 

relative  address  of  the  RCW  in  an  index  block 
after  whose  associated  key  the  "saved  key"  should 
be  inserted. 

total  size  in  words  of  the  scratch  save  area. 

This  is  defined  at  assembly  time  and  must  be  twice 
the  size  of  the  longest  key  that  is  likely  to 
occur  in  any  file. 
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7.  THE  USER'S  FILE  CONTROL  TABLE  OR  FCT 

Each  user  who  is  manipulating  a file  via  the  access  package  needs  an 
FCT  within  his  own  core  area.  It  is  used  to  hold  the  Filename,  the  relative 
statistics  pertaining  to  the  usage  of  this  file,  and  certain  internal  control 
bits . 

Table  3-9  shows  a layout  of  the  USER  FCT. 

Definitions  of  the  variables  shown  in  Table  8 are  as  follows: 

RSVD  = the  reserved  control  bits  by  which  the  access 

package  can  determine  what  the  state  of  the 
file  Is  (6  bits) 

= 0 implies  file  has  not  been  "opened"  at  all,  there- 

fore first  call  must  be  OPEN  or  DEFNFILE. 

= 1 implies  file  has  been  "opened". 

= 2 implies  file  has  been  "opened"  and  accessed 

via  any  read/write  request. 

= 77g  implies  file  has  been  "closed"  and  can  be 

subsequently  "reopened". 

R/W  * the  read/write  bit.  If  0,  the  file  may  be 

read  or  written.  If  1,  the  file  is  considered 
to  be  a "read-only"  file. 

Words  3 through  9 are  the  statistics  cells  and  have  tha  same  defini- 
tions as  those  in  the  PFAPFCT. 

8.  'IHE  FILS  INFORHMION  BLOCK  OR  FIB 

Each  data  file  has  a control  record  called  the  FIB  residing  in  the 
first  Fastrand  sector  of  the  file  on  mass  storage.  It  completely  defines  the 
organization  and  status  of  the  file. 


Table  B-10  shows  the  layout  of  the  FIB. 

The  DEFNFILE  command  Is  used  to  initially  define  the  subfields  in  the 
FIB.  An  initial  FIB  is  written  into  the  file  at  that  time.  The  OPEN  command 
causes  the  FIB  to  be  read  into  the  PFAPFCT  entry  assigned  to  this  file  (assuming 
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The  USER  FCT 
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table  B-10 


The  FILE  INFORMATION  BLOCK 
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the  file  has  not  been  already  "opened"  by  another  user).  As  each  user  performs 
a CLOSE,  a new  copy  of  the  FIB  is  written  from  the  PFAPFCT  entry  to  the  file 
assuring  an  up  to  date  status  of  the  file.  Also  whenever  a data  block  split 
occurs,  the  FIB  is  updated  since  the  data,  index  and  level  counters  may  have 
changed. 

Note  that  the  FIB  resides  within  the  data  file.  There  is  no  FIB 
within  a separate  index  file.  The  relative  sector  number  computation  involving 
data  block  numbers  must  compensate  for  the  existence  of  the  FIB.  Moreover, 
.-•iince  the  index  blocks  may  be  embedded  within  the  data  file,  the  sector  compu- 
taton  must  also  con'pensate  for  the  FIB.  Separate  index  files  therefore  have 
a Fastrand  sector  allocated  to  a dummy  FIB  (which  is  never  read  or  written) 
to  eliminate  having  the  index  block  I/O  routines  having  to  check  w.  _-th-.‘-r  the 
blocks  are  embedded  or  not. 

The  definitions  of  the  variables  shown  in  Table  B-10  are  exactly  as 
described  under  the  PFAPFCT. 

9 . ALLOCATION  OF  STORAGE  WITHIN  MODUTJE  PFAP 


The  one  non-reentrant  module  PFAP  acts  ac  a buffer  between  the 
original  caller  and  the  reentrant  portion  of  the  access  package.  Its  main 
function  is  to  save  the  caller's  registers,  t'neii  pass  on  to  the  reentrant 
modules  the  address  of  the  callor's  parameter  list  and  the  address  of  the 
register  save  and  temporary  scratch  save  area.  This  scratch  save  area  can  be 
used  by  the  reentrant  modules  to  store  counters,  flags,  etc.  of  a temporary 
file  dependent  nature.  The  maximum  size  of  this  area  is  defined  at  assembly 
time  but  shold  not  exceed  100  words. 

Table  B-11  shows  a layovit  of  the  storage  area. 

The  OPENAPFLAG  contains  a 1 bit  field  which  if  0 indicates  no  OPENAP 
has  been  performed  for  t'.iis  user;  if  1,  indicates  an  OPF.UAP  hat,  been  done. 
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STIS  DIRECTORY  FUNCTIONAL  SPECIFICATION 


1 . DIRECTORY  CAPABILITIES 


Directory  services  are  designed  to  allow  the  encoding  and  de- 
coding of  all  system  words  and  terms  (of  one  or  more  words)  used  in  STIS  as 
entity  names,  attributes  names,  attribute  values,  commands,  etc.  These  system 
words  and  terms  are  listed  in  integrated  ordered  lists  (the  Word  and  Term  En- 
coding Tables)  so  that  an  input  language  scanner  can  recognize  and  determine 
the  role  played  by  every  word  apt  to  be  input  (Including  the  attribute  associa- 
ted with  a value  term),  and  also  determine  when  a value  term  or  entity  name 
is  not  unique. 


.■i 
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1.1  DIRECTORY  TABLES 


The  Directory  Tables  are  shown  in  Figure  C-1  and  listed  in  Table  1. 
They  are  described  below. 

1.1.1  Word  Encoding  Table  (WET) 

The  WET  entries  are  three  36-bit  cells  each. 

The  input  argument  is  a word  or  word  fragment  of  one  to  twelve 
6-bit  characters.  If  the  word  or  word  fragment  is  longer  than  12  characters, 
then  C12  is  a hyphen  designating  a continued  word  fragment.  Words  of  fewer 
than  12  characters  are  left  justified  and  filled  with  blanks  (word  space)  to 
C12.  Entries  are  ordered  by  input  argument  and  words  of  arbitrary  length  can 
be  accommodated  as  a series  of  word  fragments. 

The  Role  Map  is  a 12-bit  field  which  is  used  only  if  the  word 
is  12  characters  or  less  and  represents  a one-word  term.  If  the  word  is  a 
fragment  of  a term,  then  all  12  bits  are  "0".  The  interpretation  of  the  Word 
Map  for  a tc..m  is  discussed  below  in  connection  with  the  Term  Encoding  Table. 

The  Word  Code  is  a 24-bit  field,  assigned  in  a sequence  as  words 
(and  terms)  are  entered  into  the  system. 
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Figure  C-1  Director'^  Tables 
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TABLE  1 

DIRECTORY  TABLES 


Word  Encoding  Table  (WET) 
Term  Encoding  Table  (TET) 
Term  Decoding  Table  (TDT) 
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1.1.2  Term  Encoding  Table  (TET) 

The  TET  entry  la  three  36-blt  cells.  The  input  argument  is  a 
string  of  three  24-bit  fields,  FI,  F2,  and  F3  in  which  bit  one  is  always  "0" 
and  bit  two  is  a Word  Code.  Indicator  (WCI)  which  is  set  "1"  for  a word  or  word 
fragment  code  and  "0"  for  a term  fragment  code.  The  TC  is  a term  ov  term  frag- 
ment code  and  is  24  bits  long.  (TC  corresponds  to  WC  in  the  WET  entry.) 

The  Role  Map  is  a 12-bit  field  which  is  all  "0"  if  the  input 
argument  represents  a term  fragment.  If  the  input  argument  is  a complete  term 
then  RM  represents  the  roles  of  the  term.  If  bit  i (i  “ 1,...,12)  is  “I" 
then  the  term  role  is  role  i.  For  a term,  one  or  more  of  bits  1 through  12 
will  be  set  "1".  The  role  Interpretations  are  listed  in  Table  2. 

1.1.3  Term  Decoding  Table  (TDT) 

The  TDT  entry  is  two  36-blt  cells  in  one  of  two  formats,  either 
three  24-bit  fields  or  twelve  6-bit  characters.  The  argument  is  a term  (term 
fragment)  code  or  a word  (word  fragment)  code.  Since  these  will  form  a dense 
set  (a.ssigned  in  sequence  by  the  system)  they  will  be  Interpreted  as  an  entry 
number  and  will  not  be  stored  in  the  entry  (l.e.,  the  code  is  a virtual  key).  If 
thv^  Word  Code  Indicator  (WCI)  in  the  key  is  "0"  then  the  entry  is  in  Term  Frag- 
ment Format,  otherwise,  it  is  interpreted  as  a character  string. 

In  decoding  each  term  fragment  field  the  WCI  (bit  two)  is  ex- 
amined to  determine  whether  the  corresponding  TDT  entry  should  be  interpre- 
ted in  Term  Fragment  or  Character  format.  In  this  way  terms  made  up  of  arbi- 
trarily long  strings  of  arbitrarily  long  words  may  be  decoded. 

1 . 2 DIRECTORY  .SUBSYSTEM  COMMANDS 


Each  high  level  Subsystem  command  is  generally  decomposed  into 
a series  of  lower  level  commands  which  act  on  words,  word  fragments,  or  term 
fragments.  These  lower  level  commands  then  either  search  or  make  entries  in 
the  various  tables  like  the  Term  Encoding  Table,  Word  Encoding  Table,  etc. 

This  modular  nucleus  of  word  and  fragment  oriented  commands  wii 1 allow  con- 
struction of  other  high  level  term  oriented  commands  when  needed  in  the  future. 
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1*2. 1 Term  Oriented  Commands 

A tern  is  defined  to  be  any  string  of  English  language  words  each 
of  arbitrary  length  and  separated  by  blanks  or  any  other  designated  delimiter (s) . 
The  end  of  term  is  signaled  by  an  end  of  term  sentinel  following  an  optional  last 
end  of  word  delimiter.  Information  will  be  requested  at  the  term  level  as  a re- 
sult generally  of  a query  by  an  intelligence  analyst.  The  following  commands  are 
defined  to  act  itpon  term  data. 

e Retrieve  Term  Code  and  Role  (term)  ■ (term  code, 

(role  1 <,  role  2...>)) 

This  cotmand  will  find  the  numeric  terra  code  associated 
with  the  given  English  language  term  if  the  term  code 
exists.  The  function  will  also  supply  a list  of  roles 
that  define  the  various  ways  the  term  Is  being  used.  If 
the  term  code  exists  then  at  least  one  role  will  be 
returned. 


Each  word  in  the  term  is  encoded  into  its  appropriate 
word  code  then  the  lover  level  command  'Find  Term 
Code  and  Role'  is  used  to  fetch  the  appropriate  term 
code.  If  the  term  consists  of  a single  word  then  the 
word  code  found  In  the  initial  word  encoding  process 
is  the  desired  term  code. 


Retrieve  Term  Code  (term,  role)  «»  term  code 

This  command  will  find  and  return  the  numeric  term  code 
associated  vd.th  the  given  English  language  term  pro- 
vided the  terra  exists  for  the  specified  role  in  the 
Term  Encoding  Table.  The  role  acts  as  a qualifier  for 
the  terra.  The  command  provides  the  ability  to  answer 
questions  such  as  "...is  this  term  used  as  an  attribute,,.?" 

The  function  'Retrieve  Term  Code  and  Role'  is  called  to 
find  all  the  roles  for  the  given  term,  A match  for  the 
desired  role  Is  then  sought  in  the  role  list  found. 

Find  Term  Code  and  Role  (word  code  <,  word  code,  ...  >)  ■ 
{term  code,  (role  1 <,  role  2...  >)) 

This  command  will  find  the  numeric  term  code  associated 
with  the  given  string  of  numeric  word  codes  If  the  term 
ode  exists.  The  function  will  also  supply  a list  of  roles 
that  define  the  various  ways  in  which  the  term  Is  being 
used.  If  the  term  code  exists,  then  at  least  one  role  will 
be  returned. 


Thie  cotnmand  performs  ths  tarns  functions  as  'ftetrlsvs  Tam 
Code  and  Role*  but  at  a lower  level  of  Input.  Here  It  Is 
assumed  that  the  English  term  has  been  encoded  into  Its 
word  components. 

The  word  codes  are  reencoded  recursively  via  the  'Reencode 
Fragments'  function  Into  the  term  code  desired. 

Find  Term  Code  ((word  code  <,  word  code...  >),  role  ] > term 
code 

This  connand  will  find  and  return  the  numeric  term  code 
associated  with  the  given  string  of  numeric  word  codes 
provided  the  term  code  exists  for  the  specified  role  in 
the  Term  Encoding  Table. 

Again,  this  cocmand  performs  the  same  functions  as 
'Retrieve  Term  Code*  but  at  a lower  level  of  Input. 

The  function  'Find  Term  Code  and  Role’  is  called  to  find 
all  the  roles  for  the  given  term.  A match  for  the  desired 
role  is  then  sought  In  the  role  list  found. 

This  connand  and  'Find  Term  Code  and  Role*  could  be  used 
by  a language  processor  which  scans  and  encodes  a term 
a word  at  a time  jLnto  a string  of  word  codes  and  8ubse> 
quently  desires  the  final  term  code. 

Insert  Term  (term,  role)  a term  code 

This  commend  will  effectively  add  the  English  term  quali- 
fied by  role  to  the  Term  Encoding  Table,  The  term  code 
which  is  assigned  to  It  by  the  system  will  be  returned. 

If  the  term  already  exists,  then  an  additional  role  Is  being 
defined  In  which  case  the  pre-existing  term  code  is  re- 
turned. If  both  the  term  and  role  pre-exist  then  an  error 
status  Is  returned. 

The  term  is  encoded  Into  Its  string  of  word  codes.  Appro- 
priate entries  are  made  into  the  dictionary  for  any  new 
words  encountered.  The  string  of  word  codes  are  further 
encoded  Into  term  fragments  and  subsequently  Into  a single 
unique  numeric  term  code.  The  appropriate  role  is  set  and 
the  entry  made  In  the  Term  Encoding  Table.  Entries  are 
also  made  in  the  Term  Decoding  Table  during  the  process  to 
permit  proper  retranslation  Into  English. 

Equate  Term  (new  term,  old  term,  old  role)  « term  code 
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This  cottmand  will  find  the  numeric  term  code  for  the 
given  old  English  language  term.  It  will  encode  the  new 
term  to  the  point  of  assignment  of  a unique  term  code. 

At  this  point,  the  old  term's  code  number  will  be  assigned 
as  %^11  as  the  old  role  type  indicated.  The  "new"  entry 
with  the  appropriate  role  set  Is  made  In  the  Term  Encoding 
Table.  Entries  Involving  term  fragments  are  made  In  the 
Term  Decoding  Table;  however,  no  final  entry  Involving  the 
"new"  term  code  Is  made  since  the  old  term  decoding  Is  con> 
sldered  to  be  the  "reference"  term. 

The  old  numeric  term  code  will  be  returned.  However  If  the 
old  term  code  or  old  role  does  not  exist,  then  an  error  status 
Is  returned. 

e Decode  Term  (term  code)  ■>  term 

This  command  decodes  the  given  term  code  into  the  English 
language  text  of  the  term.  The  Term  Decoding  Table  is 
used  in  a recursive  look-up  process  until  the  final  text 
la  completely  generated. 

The  term  code  lu  entered  as  an  Initial  entry  In  a push 
down  table.  A loop  is  then  begun  In  which  the  first 
entry  in  the  push  down  table  is  examined.  If  the  entry 
has  the  Word  Code  Indicator  bit  set,  then  the  entry  Is 
decoded  Into  English  text  via  'Decode.  Word'  function. 

The  text  Is  then  concatenated  with  any  previously  decoded 
text.  A 'blank*  character  Is  added  to  the  text  if  the 
word  Is  not  marked  as  'continued'.  This  entry  is  then 
completely  processed  and  the  push  down  stack  is  then  popped. 

If  the  entry  does  not  have  the  WCI  bit  set,  then  the  de- 
coding entries  are  retrieved  and  entered  in  the  push  down 
stack  in  place  of  the  first  entry.  Another  iteration  In  the 
loop  Is  then  begun.  Wlicn  the  push  down  stack  Is  empty  the 
generated  text  is  returned. 


1.2.2  Word  Orieated  Commands 


A word  Is  defined  as  an  English  language  word  of  arbitrary  character 
length  and  followed  by  a blank  or  other  designated  dellmlter(s) . Words  are 
partitioned  on  twelve  character  boundaries  If  they  exceed  twelve  characters.  The 
following  commands  are  defined  to  act  upon  words, 

• Encode  Word  (word)  > word  code 

This  command  will  attempt  to  find  the  associated 
numeric  word  code  for  the  given  English  word.  The  word 
code  Is  returned  If  found  or  an  error  status  Is  set  If 
not  found. 
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If  the  trord  Is  partitioned  due  to  its  size,  a fragment 
code  list  is  generated  and  the  'Reencode  Fragments' 
function  is  used  to  find  the  unique  desired  word  code. 

Insert  Word  (word)  ■ word  code 

This  command  will  add  the  English  Mord  to  the  Word  En- 
coding Table.  The  numeric  word  code  assigned  to  it  by 
the  system  will  be  returned.  If  the  word  is  partitioned 
due  to  its  size,  then  the  appropriate  fragment  entries  are 
also  made  in  the  Word  Encoding  Table.  Entries  are  also 
made  in  the  Word  Decoding  Table  (which  is  integrated  with 
the  Term  Decoding  Table)  for  proper  retranslation  to 
English.  The  Word  Code  Indicator  bit  Is  set  for  those 
entries  made  in  the  Word  Encoding  Table.  However  for  frag- 
ments which  need  further  encoded  entries  in  the  Term  En- 
coding Table,  the  WCl  bit  is  not  set. 

Equate  Word  (new  word,  old  word) 

This  command  allows  the  user  to  synonymlze  a new  word 
not  in  the  dictionary  with  a pre-existing  word.  The 
final  encoding  of  the  new  word  is  equated  to  the  word 
code  for  the  old  word.  This  entry  is  then  made  in  the 
Word  Encoding  Table  for  new  words  that  are  not  partitioned 
or  in  the  Term  Encoding  Table  for  words  which  are  parti- 
tioned. Appropriate  entries  are  made  in  the  Decoding 
Table  for  proper  retranslation  into  English.  If  the  old 
word  does  not  exist,  an  error  status  is  returned. 

Find  Word  Code  (word  fragment)  * word  code 

This  command  is  used  to  find  a numeric  word  code 
associated  with  a given  fragment  of  an  English  word.  If 
a single  word,  as  mentioned  earlier,  contains  more  than 
the  maximum  number  of  characters  representable  in  the 
Word  Encoding  Table,  it  is  partitioned  Into  fragments. 

Bach  fragment  then  is  assigned  a word  code  which  is  re- 
trievable via  this  command. 

Any  word  of  size  less  than  the  maximum  number  of  characters 
before  partitioning  may  be  given  aa  an  argument  to  this 
comntand. 

If  the  word  code  is  not  found  in  the  Word  Encoding  Table, 
an  error  status  is  returned. 

Decode  Word  (word  code)  <•  word 

The  character  string  represented  by  the  given  word  code  la 
retrieved  from  the  Decoding  Table  and  returned.  This 
function  would  generally  be  called  by  the  command  'Decode 
Term*  when  it  has  determined  that  it  has  encountered  a 
word  code  with  the  Word  Code  Indicator  bit  set. 
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Commands  For  Words  and/oi  Terms 


TThe  following  commands  accept  fragment  codes  as  parameters.  These 
fragment  codes  may  be  interpreted  as  either  v;ord  fragment  codes  or  term  fragment 
codes  depending  on  the  calling  command, 

a Re-encode  Fragments  (frag  code,...)  = Word/Term  code 

This  command  accepts  a string  of  fragment  codes  and 
atfempts  to  further  encode  them  into  a single  code 
via  the  Term  Encoding  Table.  The  code  found  in  the 
encoding  process  is  returned.  If  a code  is  not  found, 
an  error  status  is  returned, 

s Insert  Fragments  ((frag  code,...),  Word/Term  code,  role, 
equate  flag} 

This  command  forms  entries  for  the  Term  Encoding  Table 
using  the  fragment  code  list  supplied.  Each  packet  entered 
into  the  TET  is  assigned  a new  code  number.  The  last  entry 
Into  the  TCT  is  given  the  Word/Term  code  number  supplied  in 
the  parameter  list.  The  role  supplied  is  also  given  to  this 
final  entry. 

As  each  entry  is  made  into  the  TET,  an  appropriate  entry 
is  also  made  In  the  Term  Decoding  Table.  However  no  entry 
is  made  in  the  TDT  for  the  last  TET  entry  if  the  'equate' 
flag  is  set.  The  'equate'  flag  is  set  whenever  'Equate 
Tem'  or  'Equate  Word'  is  the  calling  function. 

1.2.4  Miscellaneous  Functions 


Several  low  level  modules  are  defined  in 
outlined  in  1.2.1,  1.2.2,  and  1.2.3.  These  modules  are 
f i-owchm’-cs  but  not  formally  defined  here. 


the  support  of  the  commands 
shown  In  the  accompanying 
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APPENDIX  D.  BASIC  NODE  FUNCTIONS 
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BASIC  NODE  FUNCTIO?:S 


1.  BASIC  DATA  OPERATIONS 


Data  services  will  be  provided  for  the  creation,  maintenance, 
and  retrieval  of  nodal  Information  based  on  the  implementation  of  the  new 
node  structure.  These  services  are  intended  to  provide  all  information  ser- 
vices supplied  by  the  current  STIS. 


A set  of  functions  are  specified  which  operate  on  a node  re- 
siding either  in  the  Semantic  or  Entity  Net  areas  of  the  STIS  Concept  Net. 
The  functions  can  be  grouped  Into  Che  following  broad  categories: 


(a)  Create 

(b)  Maintenance 

(c)  Retrieve 

These  functions  are  defined  at  the  noae  processor  level  and  are  accessible 
by  the  STIS  intermediate  language  processor  and  possibly  by  user  written 
applications  programs. 

The  special  symbols  used  in  delimiting  parameters  in 
the  following  functional  illustrations  are  defined 
as  follows; 


(new  nodes  assigned  and  created) 

(existing  nodes  expanded,  changed , 
deleted,  or  displayed) 

(existing  nodes,  and/or  data  located 
or  accessed) 


,.  1 


(1)  < arg  > implies  some  value  of  "arg"  must  be 

coded  where  "arg"  can  take  one  of 
several  values  (i.e.,  ■'  arg  > ::v^| 
V2|... |vn) 


[arg]  Implies  this  parami'ter  is  optional 

CREATE  FUNCTIONS 

The  "Create"  category  of  functions  includes  the  following: 
• Create  Entity  Node  (<AOR>)  = Node  ID 
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Create  Value  Node  (<AOR>)  = Node  ID 

Create  Term  Node  (<AOR>)  = Node  ID 

Create  Word  Node  (<AOR>)  = Node  ID 

Create  Node  (mode  type>,  <A0R>)  = ID 

where  node  type  ::  entity | attribute | value j term |word 

AOR  = Area  of  Responsibility  identifier 

Node  ID  = Tne  integer  number  assigned  to 
this  node  (and  henceforth  by 
which  it  will  be  accessed)  by 
the  storage  allocator. 


These  functions  will  add  a node  of  the  specified  type  to 
the  concept  net.  The  space  Is  allocated  in  the  node  data 
base  and  the  identifier  returned  to  the  caller.  The  node 
is  initially  created  in  the  user's  work  space.  (Subsequent 
windup  operations  for  a fact  store  will  generally  cause  the 
node  to  actually  be  written  to  mass  storage.) 

• Create  Subnode  (<Noce  ID>)  = Sub-Node  ID 

The  parent  node  is  brought  into  the  user's  workspace  if  it 
does  not  already  exist  there.  The  next  available  sub-node 
number  is  fetciied  from  the  parent  node  and  the  sub-  node  ID 
is  forired  and  returned  to  the  caller. 


MAINTENANCE  FUNCTIONS 

The  "Maintenance"  category  includes  the  large.st  number  of  func- 
It  includes  the  following: 

• Store  Fact  (value,  attr  ID,  < Fact  Control  >, 

[<  mode  >,  < Fact  Seq  if  >], 

[<  Footnote  type  >,  text  ) 

where  value  = actual  numeric,  string,  list,  etc. 
value  of  the  attribute 

attr  ID  node  ID  of  the  attribute 

Fact  Control  = one  or  more  of  the  following 

qualifiers:  Area  of  Responsi- 

bility, Classification,  sensor, 
credibility,  etc. 


Siode  ;;  Insert  | Modify 

Fact  Seq^  ■ Fact  sequence  number  in  a multi- 
fact  situation 

Footnote  Type  ::  romr.ent  | warning  j text 

Text  ■ alphanumeric  textual  data  of  the  footnote 


This  fvmccion  stores  the  actual  value  against  the  specified 
attribute  for  the  "current"  node  previously  located  or  created 
by  the  user.  The  fact  control  information  and  optional  foot- 
note text  is  also  stored  with  the  value.  If  the  attribute 
does  not  exist  in  the  current  node,  then  the  attribute/value 
pair  is  stored.  If  the  attribute  pre-exists  and  a value  with 
the  exact  Fact  Contrcl  parameters  is  found,  then  the  first  old 
value  IS  overwritten  by  the  new  value  if  the  "mode"  and  Fact 
Sequence  # fields  were  omitted.  The  "mode"  and  Fact  Sequence 
P fields  determine  the  action  to  be  taken  in  the  case  of  pre- 
existing facts.  Facts  are  implicitly  numbered  1 through  n. 

The  "mode''  argument  allows  the  insertion  of  new  facts  and  the 
modification  of  old  facts.  Insertions  occur  after  the  fact 
number  specified  in  the  Fact  Sequence  number  field.  If  it  is 
necessary  to  insert  a new  value  before  the  first  pre-existing 
value,  then  the  Fact  Sequence  II  field  = 0.  An  old  value  may 
be  modified  by  specifying  its  Fact  Sequence  number.  (Note  a 
"modify"  of  Fact  Sequence  #0  is  not  permitted.) 

• Stora  Footnote  (attr  ID,  <Fact  Control>,  [<raode>, 

<Fact  Seq.  //>,  <Foot  Seq.  ('>]  , 

<footnote  type>,  text) 

where  attr  ID  = node  ID  of  the  attribute 

Fact  Control  = one  or  more  of  the  following 
qualifiers:  Classification, 

sensor,  credibility,  etc. 

mode  : : Insert |Modify 

Fact  Seq  //  = Fact  Sequence  Number 

Foot  Seq  II  - Footnote  Sequence  Number 

footnote  type  ::  couunent  | warning  ] text 

text  = alphanumeric  textual  data  of  the 
footnote 

The  function  will  store  a footnote  for  a value  qualified  by 
the  given  Fact  CotitroJ  undT  the  given  attribute.  A sorrch 
is  made  for  the  given  att:  .butp  under  the  current  node.  If 
it  is  not  found,  an  error  status  is  returned.  If  the  attri- 
bute Is  found,  a search  is  made  for  the  correct  Fact  Control 
qualified  value.  It  not  found,  an  error  status  is  returned. 
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If  found,  the  footnote  is  stored.  The  text  may  replace  a 
previous  footnote  of  the  same  type  in  which  case  the  "mode" 
and  Footnote  Sequence  il  fields  are  examined.  The  Footnote 
Sequence  It  fiolf’  .Is  which  specific  footnote  is  to  be 

modified  or  afre  i i.  ^h.  new  footnote  will  follow.  Multi- 
fact situations  ».e  processed  using  the  Fact  Seq.  It  field 
as  described  in  Store  Fact. 


• Delete  value  (attr  ID,  < Fact  Control  [<Fact 

Sequence  II  >]) 

where  attr  ID  = node  ID  of  the  attribute 

Fact  Control  = one  or  more  of  the  following 

qualifiers:  Area  of  Responsi- 

bility, classification,  sensor, 
credibility,  etc. 

Fact  Sequence  It  = Fact  Sequence  Number 

The  function  deletes  the  specific  Fact  Controlled  value  (includ- 
ing attached  text)  for  the  given  attribute  for  the  "current"  node 
previously  specified  by  the  user,  other  existing  values  are  not 
affected.  The  Fact  Sequence  Number  specifies  the  unique  fact 
in  the  multi-fact  case.  If  the  specified  value  cannot  be  found, 
an  error  status  is  returned. 

• Delete  Attribute  (attr  ID) 

where  attr  ID  = node  ID  of  the  attribute 


This  function  will  delete  the  specified  attribute  under  the 
current  node.  All  values  and  associated  text  for  this  attri- 
bute are  likewise  deleted.  If  the  specified  attribute  does 
not  exist  within  the  current  node,  an  error  status  is  returned. 

• Delete  Footnote  (attr  ID,  <Fact  Control>, 

[<Fact  Seq.  It>t  <Foot  Seq  it>  \ , <footnote 
type>) 

wheie  attr  ID  = node  ID  of  the  attribute 

Fact  Control  = one  or  more  of  the  following 

qualifiers:  Area  of  Responsi- 

bility, classification,  sensor, 


The  function  deletes  the  text  of  the  specified  footnote  for  the 
given  Fact  Controlled  value.  Other  text  is  not  affected  as  are 
other  Fact  Controlled  values  not  affected.  An  error  status  is 
returned  on  any  'no  find'  condition.  The  Fact  Sequence  Number 
specifies  the  unique  fact  in  the  multi-fact  case.  The  Footnote 
Sequence  Number  specifies  the  unique  footnote  in  the  multi-footnote 
case. 

• Display  Node  (node  ID) 

This  function  lists  the  configuration  of  the  node 
in  the  Concept  Net  specified  by  the  node  ID. 

• Display  Attributes  (node  ID) 

This  function  lists  all  the  attributes  stored  in 
the  specified  node. 


RETRIEVE  FUNCTIONS 


The  "Retrieve"  category  of  functions  includes  the  following: 

• Retrieve  Node  (node  ID) 

The  function  locates  the  node  specified  by  node  ID 
In  the  concept  net  and  logically  loads  It  into  the 
user's  workspace.  It  becomes  the  "current"  node. 

e Retrieve  Fact  (attr  ID,  < Fact  Control  >, 

(<  Fact  Seq  //  >]  ■ value (s) 

where  attr  ID  « node  ID  of  the  attribute 

Fact  Control  ■ one  or  more  of  the  following 

qualifiers:  Area  of  Responsi- 

bility, classification,  sensor, 
credibility,  etc. 

Fact  Seq  //  » Fact  Sequence  Number 


This  function  returns  a value  or  value  list  to  the  caller  for 
the  attribute  specified  for  the  "current"  node.  If  the  attribute 
is  not  found  or  the  proper  Fact  Control  qualifiers  cannot  be 
found,  an  error  status  is  returned.  The  Fact  Sequence  Number 
field  specifies  the  unique  fact  in  the  multi-fact  case.  If  a 
warning  is  attached  to  the  fact,  this  indication  is  also  returned 
with  the  value(s).  The  value  may  be  a single  datr  item  or  an 
array  of  data  items.  The  value (s)  may  also  have  been  generated 
by  an  external  program  called  as  a part  of  the  internal  node 
processing  function. 


• Retrieve  Footnote  (attr  ID,  <Fact  Control^, 

(<Fact  Seq.  //>,  <Foot  Seq  #>]  , 
<£ootnote  type>)  ■ text 

where  attr  ID  “ node  ID  of  the  attribute 

Fact  Control  « one  or  -'..  re  ov  i;he  following 

qualifiers.  Area  of  Responsi- 
billf'v,  cia&.'ilf ication,  sensor, 
credibility,  etc. 

Fact  Seq  # = Fact  Sequence  Number 

Foot  Seq  # “ Footnote  Sequence  Number 

footnote  type  comment | warning ] text 

The  function  returns  the  alphanumeric  text  of  the  footnote 
type  specified  to  the  caller.  The  attribute  is  sought, 
then,  the  proper  Fact  Controlled  value,  then  the  specified 
footnote.  If  any  search  condition  results  in  a 'no  find', 
an  error  status  is  returned.  The  Fact  Sequence  Number  spec- 
ifies the  unique  fact  in  the  multi-fact  case.  The  Footnote 
Sequence  Number  specifies  the  unique  footnote  in  the  multi- 
footnote case. 
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MISSION 
of 

Rome  Air  Development  Center 


FADC  plans  and  conducts  research,  exploratory  and  advanced! 
development  progrr«i«s  in  axmand,  control , : and  coirnnunications 
(C^)  activities,  and  in  the  areas  of  infarction  sciences 
and  intelligence.  The  principal  technical  adssion  arses 
are  communications,  electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  miprowave 
physics  and  electronic  reliability , maintainability  and 
compatibility.. 
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